BeroFTPD

[Bernhard Rosenkraenzer]

Hello,
I've just released BeroFTPD 1.0.1, a wu-ftpd derived ftp server program
fixing some wu-ftpd bugs and adding a few more features.

Anyone willing to build a debian package?

(the .tar.gz can be found at ftp://linux.net.eu.org/pub/BeroFTPD)

LLaP
bero

-- [EMAIL PROTECTED] - ICQ/UIN 6545964 - http://www.star-trek.ml.org/ --

"Nobody will ever need more than 640k RAM!"
   -- Bill Gates, 1981
"Windows 95 needs at least 8 MB RAM."
   -- Bill Gates, 1996
"Nobody will ever need Windows 95."
   -- logical conclusion



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

Re: base-files 1.6 (source all) uploaded to master

[Nicolás Lichtmaier]

>   I append my personal prompt setting scheme, in hopes this
>  inspires someone else (any improvements greatly appreciated)

 Uhh..! You must have lots of free time!


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

Re: FILESYSTEM CORRUPTION

[Stephen Zander]

> "John" == John Goerzen <[EMAIL PROTECTED]> writes:
[snip]
John> not umount local drives.  Therefore, I believe it would be
John> prudent, as a temporary workaround for the kernel bug, to
John> umount all local drives before umounting network drives.  It

No, that won't work if the NFS mounts live below the local mounts in
the file-system tree.  The local mounts will report busy.

John> PCMCIA services are turned off before the network is turned
John> off, apparently.  This causes difficulty, for instance, if
John> the laptop is acting as an NFS server, as mine does.  (Great
John> way to carry data around!)  If I forget to umount it from
John> the NFS client (my desktop machine), I can have two
John> problems:


John>  * When I shutdown my desktop, it will hang trying to
John> umount.

I suggest looking at the options you're using on the NFS client.  Try
soft mounting & see if that will let you umount the NFS volume.

John>  * When I shutdown my laptop, it will hang trying to turn
John> off PCMCIA.

That probably does need fixing.

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


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

Re: sleep contains crypto stuff?

[Martin Schulze]

Do we consider this as a bug that should be fixed in shellutils?

Apart from that, I thought that gcc and tools are intelligent
enough to only link routines and libraries to executables if
there are routines from them used.  If there are no crypto
routines used in these programs (e.g. sleep), I have to admit
that I'm little disappoined by gcc & tools (such as ld).

Regards,

Joey


-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 / The good thing about standards is /
/ that there are so many to choose from. -- Andrew S. Tanenbaum /


pgpiCYJBu0sEX.pgp
Description: PGP signature

Re: Is this a bug in libc6?

[Manoj Srivastava]

Hi,
>>"Steve" == Steve Greenland <[EMAIL PROTECTED]> writes:

Steve> On 10-Apr-98, 18:00 (CDT), Manoj Srivastava
Steve> <[EMAIL PROTECTED]> wrote:
>>  I have looked at the standards to shed some liight on this
>> subject, and I failt to see any statements that a second flose is
>> cause for undefined behaviour, asuming you meant the technical term
>> ``undefined'' when you say "not defined".

Steve> My copy of the standard is at work, but I think there's a
Steve> statement near the beginning of the  section that says
Steve> calling any of the I/O functions with an invalid FILE * is
Steve> causes undefined behaviour. If anybody really cares, I'll look
Steve> Monday.

Please look further in my message, I do prove that indeed this
 is undefined behaviour. The above paragraph is my mind taking a
 vacation. 


>> >> A double fclose is just as bad as a double free() and is not a
>> library error should it fault or corrupt memory.
>> 
>> Hola! Corupting memory is not acceptable behaviour! (Unless you
>> document this)

Steve> Sure it is. Go read the definition of "undefined behaviour"
Steve> again -- "this standard imposes no requirment". It can corrupt
Steve> memory, re-format your hard disk, or make monkeys fly out of
Steve> your nose; all of these are ISO C compliant.

--
1.6 Definitions of terms

o Undefined Behaviour -- behaviour, upon the use of a nonportable or
  erroneous program construct, of erroneous data, or of inderminately
  valued objects, for which the standard imposes no
  requirements. Permissible undefined behaviour ranges from ignoring
  the situation completely with unpredictable results, to behaving
  during translation or program execution in a documented manner
  charecteristic of the environment (with or without the issuance of a
  diagnostic message), to terminating a translation or execution (with
  the issuance of a diagnostic message).

If a "shall" or "shall not" requirements that appears outside
 of a constraint is violated, the behaviour is undefined. Undefined
 behaviour is otherwise indicated in this standard by the words
 "undefined behaviour" or by the omission of any explicit definition
 of behavior. There is no difference in emphasis among these three;
 they all describe "behaviour that is undefined."

o Unspecified behaviour -- behaviour, for a correct program construct
  and correct data, for which the standard explicitly imposes no
  requirements.

__

Please show why my statement is incorrect wrt to the above
 statement from the C standard. I said: "Corupting memory is not
 acceptable behaviour! (Unless you document this)". The standard says
 "permissible undefined behaviour ..."

I understand that it is fashionable in comp.lang.c to say that
 undefined behaviour means "It can corrupt memory, re-format your hard
 disk, or make monkeys fly out of your nose; all of these are ISO C
 compliant.", but the standard does make a statement about permissible
 undefined behaviour, and unless such action is documented, it is not
 permitted by the standard.

manoj
-- 
 In article ... [EMAIL PROTECTED] (Wee Willie) writes: Well
 I guess the summary says it all, where do I find Sports Illustrated
 GIF's or anything similar   I violate copyright and I'm OK, I
 view all night and I scan all day. He violates copyright and he's OK,
 he views all night and he scans all day. I buy magazines at the
 corner store, When I've scanned them all, I'll buy some more. He buys
 magazines at the corner store, When he's scanned them all he'll buy
 some more.  Well, you get the idea... J Eric Townsend
 ([EMAIL PROTECTED])
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: Is this a bug in libc6?

[Gregory S. Stark]

Manoj Srivastava <[EMAIL PROTECTED]> writes:
> --
> 1.6 Definitions of terms
> 
>   ... Permissible undefined behaviour ranges from ignoring
>   the situation completely with unpredictable results, to ...
> __
> 
>   Please show why my statement is incorrect wrt to the above
>  statement from the C standard. I said: "Corupting memory is not
>  acceptable behaviour! (Unless you document this)". The standard says
>  "permissible undefined behaviour ..."
> 
>   I understand that it is fashionable in comp.lang.c to say that
>  undefined behaviour means "It can corrupt memory, re-format your hard
>  disk, or make monkeys fly out of your nose; all of these are ISO C
>  compliant.", but the standard does make a statement about permissible
>  undefined behaviour, and unless such action is documented, it is not
>  permitted by the standard.


Making monkeys fly out of my nose certainly sounds unpredictable to me.

greg


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

Re: Is this a bug in libc6?

[Anthony Towns]

On Fri, Apr 10, 1998 at 06:00:50PM -0500, Manoj Srivastava wrote:
>   That is why I prefer to do:
> 
>   free(ptr);
>   ptr = 0;
> --
>   (similarily for fclose).

Ditto, however in this case:

] $ cat test.c
] #include 
] int main(void) {
]   FILE* f;
]   f = NULL;
]   fclose(f);
]   return 0;
] }
] $ gcc -Wall -W -ansi -pedantic -o test test.c
] $ ./test
] Segmentation fault
] $ _

I couldn't find anything that says that's not allowable (cf free(NULL);
which is defined as harmless), but at the very least the manpages need 
to be changed to reflect the actual behaviour here.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. PGP encrypted mail preferred.

  ``It's not a vision, or a fear. It's just a thought.''


pgp2ouXmWxYFH.pgp
Description: PGP signature

Re: Is this a bug in libc6?

[Herbert Xu]

In article <[EMAIL PROTECTED]> you wrote:
> --
> 1.6 Definitions of terms

> o Undefined Behaviour -- behaviour, upon the use of a nonportable or
>   erroneous program construct, of erroneous data, or of inderminately
>   valued objects, for which the standard imposes no
>   requirements. Permissible undefined behaviour ranges from ignoring
>   the situation completely with unpredictable results, to behaving
>   during translation or program execution in a documented manner
>   charecteristic of the environment (with or without the issuance of a
>   diagnostic message), to terminating a translation or execution (with
>   the issuance of a diagnostic message).
> __

>   Please show why my statement is incorrect wrt to the above
>  statement from the C standard. I said: "Corupting memory is not
>  acceptable behaviour! (Unless you document this)". The standard says
>  "permissible undefined behaviour ..."

It also says that the standard imposes no requirements.

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


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

[grave] libstdc++2.8 needs versioned dependencies

[Dirk Eddelbuettel]

severity 20033 grave
stop

I just received another bug report (#20978) on Octave not being able to
run. I had already reassigned the first such report (#20033) to libstdc++2.8
which does *not* introduce versioned dependencies on its libs even though it
is incompatible with the previous release. Because of the missing versioned
dependency, dpkg thinks that the older (first-generation) libstdc++2.8
package satisfy the dependencies.

This is not the case --- and as libstdc++2.8_2.9.27 is in hamm, it is likely
that this will break other C++ compiled packages. I strongly feel that this
*must* be fixed in hamm.

For the record, I also upgraded (after building Octave 2.0.11.91 earlier
today) to the newest libstdc++2.8_2.90.27_0.3 which still has an insufficient
shlibs file:

[EMAIL PROTECTED]:/var/lib/dpkg/info> cat libstdc++2.8.shlibs 
libstdc++ 2.8 libstdc++2.8


-- 
mailto:[EMAIL PROTECTED]  According to the latest official figures, 
http://rosebud.ml.org/~edd  43% of all statistics are totally worthless.


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

Re: Is this a bug in libc6?

[Manoj Srivastava]

Hi,
>>"Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes:

Herbert> In article <[EMAIL PROTECTED]> you wrote:
>> --
>> Definitions of terms

>> o Undefined Behaviour -- behaviour, upon the use of a nonportable
>> or erroneous program construct, of erroneous data, or of
>> inderminately valued objects, for which the standard imposes no
>> requirements. Permissible undefined behaviour ranges from ignoring
>> the situation completely with unpredictable results, to behaving
>> during translation or program execution in a documented manner
>> charecteristic of the environment (with or without the issuance of
>> a diagnostic message), to terminating a translation or execution
>> (with the issuance of a diagnostic
>> message). 
>> __

>> Please show why my statement is incorrect wrt to the above
>> statement from the C standard. I said: "Corupting memory is not
>> acceptable behaviour! (Unless you document this)". The standard
>> says "permissible undefined behaviour ..."

Herbert> It also says that the standard imposes no requirements.

Look at the whole sentence, please. There are indeed no
 requirements for the program to behave in any fashion; as long as the
 behavioue is documented (and is characteristic of the environment --
 monkeys flying out of the users nose is out); if it is not
 documented, you can ignore the construct, or terminate translation or
 execution (issueing a diagnostic is required then).

I know fashionable, but incorrect, comments on comp.lang.c
 would have it otherwise.

manoj
 
-- 
 "I can't face the world in the morning. I must have coffee before I
 can speak." Joseph Cotton in Shadow of a Doubt
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: Is this a bug in libc6?

[Manoj Srivastava]

Hi,
>>"Gregory" == Gregory S Stark <[EMAIL PROTECTED]> writes:

Gregory> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> --
>> Definitions of terms
>> 
>> ... Permissible undefined behaviour ranges from ignoring the
>> situation completely with unpredictable results, to
>> ... __
>> 
>> Please show why my statement is incorrect wrt to the above
>> statement from the C standard. I said: "Corupting memory is not
>> acceptable behaviour! (Unless you document this)". The standard
>> says "permissible undefined behaviour ..."
>> 
>> I understand that it is fashionable in comp.lang.c to say that
>> undefined behaviour means "It can corrupt memory, re-format your
>> hard disk, or make monkeys fly out of your nose; all of these are
>> ISO C compliant.", but the standard does make a statement about
>> permissible undefined behaviour, and unless such action is
>> documented, it is not permitted by the standard.


Gregory> Making monkeys fly out of my nose certainly sounds
Gregory> unpredictable to me.

Firstly, read the whole sentence.
 Permissible undefined behaviour ranges from ignoring the situation
 completely with unpredictable results 
 
  ignoring the situation completely with unpredictable results 

   ignoring the situation completely 

   ignoring the situation ...

get it? If ignoring a second fclose makes monkeys fly out of
 your nose, then fine. You have a strange nose.

manoj
 Also: the standard says the results should be a characteristic of the
 environment. If flying monkies is a characteristic of your nose, I
 still say you have a strange nose.

-- 
 "I ... reject the argument put forth by many fundamentalists that
 science has nothing to do with religion because God is not among the
 things making up the universe in which we live.  Surely if a
 necessity for a god-concept in the universe ever turns up, that
 necessity will become evident to the scientist." physicist Ralph
 Alpher, "Theology of the Big Bang," Religious Humanism, Vol. XVII,
 No. 1 (Winter 1983), pg. 12
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Intent to package chameleon

[Shaleh]

This is a program that uses GTK and imlib to draw pix onto the root
window, or just colors.  It is like xv in this respect.  it is fully GPL
and has no problems.


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

Re: Is this a bug in libc6?

[Steve Greenland]

On 11-Apr-98, 00:12 (CDT), Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Hi,
> >>"Gregory" == Gregory S Stark <[EMAIL PROTECTED]> writes:
> 
> Gregory> Manoj Srivastava <[EMAIL PROTECTED]> writes:
> >> --
> >> Definitions of terms
> >> 
> >> ... Permissible undefined behaviour ranges from ignoring the
> >> situation completely with unpredictable results, to
> [snip by sg] 
> 
>   Firstly, read the whole sentence.
>  Permissible undefined behaviour ranges from ignoring the situation
>  completely with unpredictable results 
>  
>   ignoring the situation completely with unpredictable results 
> 
>ignoring the situation completely 
> 
>ignoring the situation ...
> 
>   get it? If ignoring a second fclose makes monkeys fly out of
>  your nose, then fine. You have a strange nose.

I think you've misread that sentence. The situation it is permissible
to ignore is the fact that a construct invoking undefined behaviour
has occurred (e.g. a second call to fclose() with the same FILE *).
The library is free to attempt to try to "close" whatever the garbage
is pointed to...which may lead to a hard disk re-format, or on certain
embedded implementations, monkeys issuing from the nose. I don't *think*
the implementation is required to catch the fact that it's an invalid
FILE *, and then ignore the attempt to fclose().

This actually *is* almost worth asking on comp.std.c; I've never
interpeted that sentence the way you're interpeting it, but I can
see your point of view.

steve


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

Re: Is this a bug in libc6?

[Manoj Srivastava]

Hi,

It is also a quality of implementation issue. I have no
 objections to am implementation documenting that a second call to
 fclose shall result in indeterminate behaviour, and then not catching
 that the structure is no longer an active  FILE *  stream. 

I do have a problem with the implementation not documenting
 the action, if it is not a benign ignoring of the second call (which
 may or may not have unpredictable results), issuing a diagnostic and
 terminating either at translation or execution stage.

In other words, if the implementation is going to do anything
 strange, it has to document the behaviour.

Anything else, In my interpretation, is a violation of the
 standar, or, at least, a very poor imlemntation. I am certainly going
 to complain to my vendor if it corrupts memory or makes monkies fly
 out of peoples noses (the SPCA would have something to say about that
 too).

So, the point is not whether they implemntation can do strange
 and unexpected things; they can; but then they have to document it. 

 BTW, in Debian, fclose says it returns an error, and does not mention
 corrupting memory. 
ERRORS
   EBADF  The argument stream is not an open stream.

   The fclose function may also fail and set errno for any of
   the  errors  specified  for  the  routines   close(2)   or
   fflush(3).
close(2) says:
RETURN VALUE
   close returns zero on success, or -1 if an error occurred.

ERRORS
   EBADF  fd isn't a valid open file descriptor.

So if any memory was corrupted, report it as a bug (with
 possibly a non-normal severity) against libc6. A segfault is
 definitely not acceptable in the light of a documented rteturn
 value. Undefined does not mean that the implemntation has the right
 to mess up my machine (again, a quality of implementation issue even
 if in your judgement it does not violate the standard. I think an
 undocumented segfault is a violation of the standard).

manoj
-- 
 "To be good, according to the vulgar standard of goodness, is
 obviously quite easy.  It merely requires a certain amount of sordid
 terror, a certain lack of imaginative thought, and a certain low
 passion for middle-class respectability." Oscar Wilde
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

HTTP mirror list

[Jason Gunthorpe]

I have an updated http mirror list,

http://www.debian.org/~jgg/mastersoucelist

Let me know if there are any omissions or errors.

Thanks,
Jason


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

Re: FILESYSTEM CORRUPTION

[Kai Henningsen]

[EMAIL PROTECTED] (John Goerzen)  wrote on 10.04.98 in <[EMAIL PROTECTED]>:

> Therefore, I believe it would be prudent, as a temporary workaround
> for the kernel bug, to umount all local drives before umounting
> network drives.  It is generally not a big deal if a network drive
> doesn't get umounted anyway.

The reason local file systems can't be unmounted when NFS unmount hangs,  
is that the NFS fs is still mounted, keeping the local fs busy.

What makes you think it is possible to unmount the local fs before even  
trying to unmount the NFS fs?

*However*, a little experimenting shows that the kernel is perfectly  
willing to let you "mount /some/where -o remount,ro" even if there are  
files open on that fs. I'm not quite certain if those open files are  
guaranteed to be handled correctly, but this, possibly combined with sync,  
should be enough to get a clean shutdown.

This looks like a wishlist bug for sysvinit (which has /etc/init.d/umountfs).

MfG Kai


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

Re: What to do when dupload doesn't....

[Heiko Schlittermann]

On Fri, Apr 10, 1998 at 03:53:33PM -0700, Stephen Zander wrote:
: 
: What's the appropriate procdure when dupload fails?  Can I just
: manually ftp the files to the appropriate directory on master?

You can.

But why does dupload fail?


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]


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

Re: BeroFTPD

[Heiko Schlittermann]

On Sat, Apr 11, 1998 at 02:03:54AM +0200, Bernhard Rosenkraenzer wrote:
: Hello,
: I've just released BeroFTPD 1.0.1, a wu-ftpd derived ftp server program
: fixing some wu-ftpd bugs and adding a few more features.
: 
: Anyone willing to build a debian package?
: 
: (the .tar.gz can be found at ftp://linux.net.eu.org/pub/BeroFTPD)

As I've the wu-ftpd as well as the wu-ftpd-academ, I'd like to take
the bero ftpd to. 

It's true, for a long time I couldn't do too much for the ftpds, but the
release of a critical-bugs-fixed wu-ftpd-academ is nearly ready.  For
wu-ftpd I consider not longer maintaining it, since all it's
functionality is in wu-ftpd-academ ...

Any objections?



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]


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

Re: Number of Maintainers

[Christian Schwarz]

On Sat, 4 Apr 1998, Brian Bassett wrote:

> After both Manoj Srivastava and Bob Hilliard pointed out to me the faults
> in using the Maintainers file for determining the number of maintainers, I
> have decided to use the Debian PGP keyring.  After deleting duplicate keys,
> the keyring says that there are 313 developers, making Q 8.85 and K 5.

Note, that Tim Sailer and I are working on a Developer DB, a SQL db
where every Debian developer (maintainers and non-maintainers) are listed.
Once this DB is set up, you can use this to calculate the exact number of
developers.


Thanks,

Chris

--  _,, Christian Schwarz
   / o \__   [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
   \  / http://fatman.mathematik.tu-muenchen.de/~schwarz/
-.-.,---,-,-..---,-,-.,.-.-
  "DIE ENTE BLEIBT DRAUSSEN!"


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

PostgreSQL packages

[Oliver Elphick]

I keep getting bug reports about postgresql-6.3-2 which is the latest
one available in hamm.

It's up-to-date replacement is postgresql-6.3.1-6 which is stuck in
Incoming. That will itself be obsoleted next week, when an upstream 
bugfixing releasze is due

Please get this version; if you cannot get it from Incoming, get it
from . (Unfortunately, I don't have
enough space on that server to upload the source, so these are just
the binary packages.)
-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver

PGP key from public servers; key ID 32B8FAA1

===
God did not send his Son into the world to condemn the world, but that
the world through him might be saved. He who believes in him is not
condemned; but he who does not believe is condemned already, because he
has not believed in the name of the only begotten Son of God. And this
is the condemnation: that the light has come into the world, and men
loved darkness rather than light, because their deeds were evil.
(John 3:17-19)




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

Re: HTTP mirror list

[Hamish Moffatt]

On Sun, Apr 12, 1998 at 02:00:12AM -0600, Jason Gunthorpe wrote:
> I have an updated http mirror list,
> http://www.debian.org/~jgg/mastersoucelist
> Let me know if there are any omissions or errors.

It's a shame we don't/can't have any sought of quality of service
indicator in our mirror listing. Without wishing to speak ill
of or offend the administrator, the mirror at ftp.au.debian.org is unusable
from here. Although on the other side of the country from here,
I can still reach backbone routers over there in 274ms, yet to get
to the first router at the ISP there is over 3000ms. Basically,
despite the name ftp.au.debian.org the mirror is only usable by
customers of that provider.

Connectivity is better during off-peak hours though.

To confuse things further, there's also debian.org.au
(tech-contact is another Australian ISP, admin contact Bruce Perens),
yet ftp.debian.org.au == ftp.debian.org, ie ftp.cc.gatech.edu.


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


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

Re: Is this a bug in libc6?

[Kai Henningsen]

[EMAIL PROTECTED] (Eloy A. Paris)  wrote on 10.04.98 in <[EMAIL PROTECTED]>:

> According to fclose's man page, it will return EOF and set errno to
> EBADF if the argument is not an open stream.

That is not what the info docs for libc6 say:

Closing Streams
===

   When a stream is closed with `fclose', the connection between the
stream and the file is cancelled.  After you have closed a stream, you
cannot perform any additional operations on it.

[...]

Incidentally, the manpage seems to contradict itself; it also says that  
"no further access to the stream is possible".

MfG Kai


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

Re: Is this a bug in libc6?

[Kai Henningsen]

[EMAIL PROTECTED] (Manoj Srivastava)  wrote on 10.04.98 in <[EMAIL PROTECTED]>:

>   I understand that it is fashionable in comp.lang.c to say that
>  undefined behaviour means "It can corrupt memory, re-format your hard
>  disk, or make monkeys fly out of your nose; all of these are ISO C
>  compliant.", but the standard does make a statement about permissible
>  undefined behaviour, and unless such action is documented, it is not
>  permitted by the standard.

Bullshit.

The documentation requirement is for implementation-defined behaviour. For  
undefined behaviour, "the standard imposes no requirements". No  
requirements are no requirements. There is no requirement that such an  
action is documented.

It further says "Permissible undefined behaviour ranges from ignoring the  
situation completely with unpredictable results, ...", and those  
unpredictable results sure include memory corruption, or indeed any of the  
other stuff "fashionable in comp.lang.c".

Undefined is *un*defined.

The only interesting question here is if fclose(fp); fclose(fp); is indeed  
undefined. (Note that fp=fopen("not.there", "r"); fanything(fp); is  
undefined simply because fp is NULL.) I suspect it is, because after the  
first fclose(fp); it has "indeterminate value".

MfG Kai


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

Re: Is this a bug in libc6?

[Kai Henningsen]

[EMAIL PROTECTED] (Manoj Srivastava)  wrote on 11.04.98 in <[EMAIL PROTECTED]>:

>   Look at the whole sentence, please. There are indeed no
>  requirements for the program to behave in any fashion; as long as the

No. There are no requirements, period. Look at the sentence yourself.

>   I know fashionable, but incorrect, comments on comp.lang.c
>  would have it otherwise.

It is interesting to note that *all* members of the committee that wrote  
this standard that have ever spoken up on comp.std.c, have agreed with  
these "fashinable comments".


MfG Kai


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

DEBIAN POLICY WEEKLY, #6 (April 11, 1998)

[Christian Schwarz]

DEBIAN POLICY WEEKLY, #6 (April 11, 1998)

The following message is a list of topics related to the Debian Policy which
are currently under discussion or which will be discussed in the near
future. This summary is sent to the debian-policy mailing list periodically
by the Debian Policy Manager.

A copy of this mail is sent to debian-devel to keep other developers
up-to-date. Please send any replies to the debian-policy mailing list.

Please do not quote the whole mail if you are only referring to a single
section to save bandwidth.



The Policy Manual on the Web

This message can also be read online at

   http://schwarz.developer.debian.org/policy/weekly/

The Home Page of the Debian Policy Manual is located at

   http://schwarz.developer.debian.org/policy/

This page contains links to the current documents, information about the
current development version (2.4.1.0 DRAFT), and links to related documents.



Policy changes that need to be approved

The following policy changes have been developed during recent discussion on
the mailing lists. If there are no objections, these changes will become
`official' soon.

 1. ldconfig calls in postinst scripts

 2. Absolute and relative symbolic links

 3. Manual pages for X11 games

Policy topics about which I need additional input

The following topics have been discussed on the mailing lists or in private
mail. I need more information and personal opinions about these topics to
prepare a policy change:

 [none]

Policy topics which need to be discussed

The following ideas have been mentioned in recent discussions. Any input is
appreciated.

 [none]



Topic 1: ldconfig calls in postinst scripts

STATE: APPROVAL
REF:   cf. bug #20515

Current policy states that in general, calling `ldconfig' from the postinst
script is not necessary. There have been a few discussions on this topic
already, with the result that current policy is wrong: it *is* necessary to
run `ldconfig' in postinst scripts if the package installs a shared library
(into a directory which is listed in /etc/ld.so.conf).

Therefore, I suggest to change the Packaging Manual (last paragraph of the
preface of chapter 12) to state the following:

 Any package installing shared libraries in a directory that's
 listed in /etc/ld.so.conf must call `ldconfig' in its postinst
 script if and only if the first argument is `configure'.

 It is especially important not to call ldconfig in the postrm or
 preinst scripts in the case where the package is being upgraded
 (see Details of unpack phase of installation or upgrade, section
 6.3), as ldconfig will see the temporary names that dpkg uses for
 the files while it is installing them and will make the shared
 library links point to them, just before dpkg continues the
 installation and removes the links!



Topic 2: Absolute and relative symbolic links

STATE: APPROVAL

Current policy reads (section 3.3.5):

   ``Most symbolic links should be relative, not absolute.
 [...]
 In particular, symbolic links from one part of /usr to another
 should be relative.

 In certain cases, however, relative links may cause more
 problems. For example, links into /etc and /var should be
 absolute.''

If some discussion on debian-policy, we had a consensus about changing this
into something like the following text. If there are no objections, I'll do
so with the next release of the Policy Manual.

 In general, symbolic links within a toplevel directory should be
 relative, and symbolic links pointing from one toplevel directory
 into another should be absolute. (A toplevel directory is a
 sub-directory of the root directory `/'.)

 In addition, symbolic links should be specified as short as
 possible, i.e., link targets like `foo/../bar' are depreciated.



Topic 3: Manual pages for X11 games

STATE: APPROVAL

Current policy states that X11 games have to be installed into /usr/games,
instead of /usr/X11R6/bin. It is not yet specified, where manual pages of
such games should be installed to. I suggest to put such manual pages into
`/usr/man/man6'.

The two reasons for this are, that a) it is logical to put manual pages into
/usr/X11R6/man if and only if the documented files are installed below
/usr/X11R6, too, and b) the `man' command generates the MANPATH settings
dynamically from the PATH, and maps '/usr/games' to '/usr/man'.

Unless there are objections, I'll include a statement in the policy manual
that manual pages for X11 games should be 

RFC: splitting debian-project off debian-devel

[Christian Schwarz]

As everyone here has probably noticed already, the traffic on debian-devel
has increased again. (My debian-devel mail folder for March 98 is 8.7 mb
large!)

I guess one of the reasons is that a lot of project related discussions
which have been hold on debian-private before, are now moved to
debian-devel. (It's good to have less discussions in private--but this
made debian-devel even harder to follow.) 

The problem with having everything on a single list (the volume of
debian-devel is extremly large compared to the other debian-* lists) is
that is very hard to follow the important discussions only. (For example,
I was very busy the last weeks. I didn't had time to read all mails on
debian-devel, but I wanted to read at least the important threads about
the constitution. This was nearly impossible--even with a threaded mail
client--since such discussions don't use a single thread, but several ones
and very important mails are mixed between totally unimportant mails.) 

Therefore, I'd suggest to split off a new mailing list from debian-devel,
namely `debian-project', where all project related discussions (e.g.,
Constitution, Maintainer DB) would be held. This mailing list would be
open to the public too (like debian-devel) and we could even start with
the same subscriptor list like debian-devel. 

The new setup would allow people who are only intrested in the technical
stuff to subscribe to debian-devel only (I guess this applies for most of
the beta-testers or users of "unstable"), and would make it much easier
for the `busy Debian developers' who don't have time to follow every
single mail on debian-devel.

Comments are appreciated!


Thanks,

Chris

--  _,, Christian Schwarz
   / o \__   [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
   \  / http://fatman.mathematik.tu-muenchen.de/~schwarz/
-.-.,---,-,-..---,-,-.,.-.-
  "DIE ENTE BLEIBT DRAUSSEN!"


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

Guile packages

[Karl M. Hegbloom]

 I've decided not to take the guile packages from Jim Pick.  I don't
 have the time, I really need to study more, I'm not up to the task
 right now.  I have a nice rules file if anyone wants it.

 I've decided to put my energy into learning to use the RScheme
 system, rather than Guile.  It's a better scheme.  It would be a good
 thing, perhaps, if Gnome would look at it also.  Are there reasons
 for not doing that?


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

Re: Guile packages

[Karl M. Hegbloom]

> "Karl" == Karl M Hegbloom <[EMAIL PROTECTED]> writes:

Karl>  I've decided not to take the guile packages from Jim Pick.

 Disregard that.  I will proceed with the packages.


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

Re: intent to package Netscape Communicator

[Gregory S. Stark]

Adam Heath <[EMAIL PROTECTED]> writes:
> The nice side effect of my packaging, is that in the original tarball, you
> have to download both the static and dynamic versions.  My packaging has them
> split up.  Also, -java is the same between Navigator and Communicator.

Any chance of getting a standalone navigator as well?
It starts up much faster than the monolithic Communicator.

greg


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

Re: Is this a bug in libc6?

[Steve Greenland]

On 11-Apr-98, 02:26 (CDT), Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>   So, the point is not whether they implemntation can do strange
>  and unexpected things; they can; but then they have to document it. 
> 
>  BTW, in Debian, fclose says it returns an error, and does not mention
>  corrupting memory. 
> ERRORS
>EBADF  The argument stream is not an open stream.
> 
>The fclose function may also fail and set errno for any of
>the  errors  specified  for  the  routines   close(2)   or
>fflush(3).

Oh, sure, that's an error it *may* report, *if* it detects it. I don't
see anything on the man page that would expect me to believe that the
implementation will detect all possible invalid streams and report an
error. I am also quite willing to believe that the particular error we
are discussing (fclose(fp);fclose(fp)) will be detected.

Unfortunately, that belief is not supported. Consider the
program:

#include 

int
main (void)
{
  FILE *fp;
  if ((fp = fopen ("test.dat", "w")) == NULL)
{
  printf ("Failed to open test.dat\n");
}
  printf ("open succeed\n");
  if (fclose (fp) != 0)
{
  perror ("#1 says:");
}
  printf ("fclose #1 succeed\n");
  if (fclose (fp) != 0)
{
  perror ("#2 says:");
}
  printf ("fclose #2 succeed\n");
  return 0;
}

Compile with:

cc -g -Wall -o testclose testclose.c

The output is:

open succeed
fclose #1 succeed
Segmentation fault (core dumped)

(All the above on a hamm system that was up-to-date as of April 9th.)

While something better would be nice, I consider this completely ISO
C compliant. I can imagine a nice debugging stdio lib, the equivalent
of electric-fence or some such, which kept track of valid streams and
validated everything before use, etc etc. I'd also hate to pay the price
of those checks on a release build.

Steve


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

dpkg memory usage

[John Goerzen]

I was upgrading packages on my 64 meg system today ant noticed:

  PID USER PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
24785 root  18   0 12680  12M   568 S   0  0.1 20.0   5:36 dpkg

Yes, that's almost 13 megs used by dpkg, and 20% of my RAM.

That also is 4 megs more than the TOTAL amount of RAM in some computers I
work with.

So...why must dpkg use almost as much memory as XFree86 itself, and MORE
than Netscape does at times?

Not only that, but it is hideously slow even on current computers.  My
suggestion: store the databases in a DBM format of some sort instead of
plain text. 


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

Re: (RFD) New list proposal - debian-unstable@lists.debian.org

[Brian White]

> Currently it seems to me that debian-devel is serving two unrelated
> purposes.  On the one hand it is a forum for developers to pick each
> others brains, and ask opinions of interested debian users.
> 
> On the other hand, it also serves to monitor the status of the frozen and
> unstable distributions.

The idea of categorizing subjects by making multiple lists (or newsgroups)
is always appealing but seldom successful.  When the purpose behind a
list is not completely separate (and clearly separate, I might add), then
people are unsure where to post and then often post to them all.

Also, if we assume that people don't subscribe to both, then posting to
only one won't reach everyone and so much still be posted to both.  For
example, every week I have an automated post that tell which release-
necessary bugs are still open.  I want all developers to see this because
I want to encourage fixes from everyone -- not just the maintainers.  Thus,
I would have to include debian-devel even though it is obviously just
for the second list you describe.

  Brian
 ( [EMAIL PROTECTED] )

---
Premature optimization is the root of all evil.  -- Donald Knuth



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

Re: Debian Bug#20445 disagree

[Brian White]

> > > Also, how likely are the current versions of these programs
> > > to work with future versions of the unstable 2.1 kernel and the 2.2
> > > kernel that will eventually come from it?
> 
> True enough. But a Debian 2.1.x package and packages that works with it
> could be good for seeing and trying out. So you know what debian packages
> there are and what they provide before you even switch on your modem.
> 
> OTOH, we don't have a kernel-source package for hamm.
> 
> So you have made your point, as I have made mine.

Okay, how about this...

2.1 kernel-requiring stuff (and a current 2.1 kernel?) can be included
under "contrib".  This keeps it out of "main" and puts it into the realm
of "user-beware".  (Note:  This is not to insinuate that everything in
contrib is dangerous or anything, but just that you should think at least
once before installing it.)

Acceptable?

  Brian
 ( [EMAIL PROTECTED] )

---
 Generated by Signify v1.04.  For this and more, visit http://www.verisim.com/



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

Re: intent to package Netscape Communicator

[Brian White]

> I intend to package the new communicator that allow free redistribution.  It
> will go into non-free(no source), but at least the users won't have to
> download the tarball themselves.

That would be great!  I posted a couple weeks ago asking for someone to
help with this because I don't have the time for it.

I'd like to coordinate so we can use the same wrapper scripts, plugins, etc.

  Brian
 ( [EMAIL PROTECTED] )

---
   Touch passion when it comes your way.  It's rare enough as it is;
   don't walk away when it calls you by name.  -- Marcus (Babylon 5)



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

Re: intent to package Netscape Communicator

[Brian White]

> > Just so there's no confusion: you're refering to the Netscape-branded
> > product, right?
> 
> I think we should use the following nomenclature -
> 
> 1. Mozilla - Sources and binaries compiled from the sources downloaded from
> http://www.mozilla.org/
> 
> 2. Netscape Communicator - Binaries downloaded from
> http://home.netscape.com/ and repackaged in .deb format.

Don't forget "netscape installer".

  Brian
 ( [EMAIL PROTECTED] )

---
 Two roads diverged in a wood, and I -- I took the one less travelled by,
 And that has made all the difference.  ("The Road Not Taken" -- Robert Frost)



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

Re: intent to package Netscape Communicator

[Adam Heath]

On Sat, 11 Apr 1998, Brian White wrote:

> > I intend to package the new communicator that allow free redistribution.  It
> > will go into non-free(no source), but at least the users won't have to
> > download the tarball themselves.
> 
> That would be great!  I posted a couple weeks ago asking for someone to
> help with this because I don't have the time for it.
> 
> I'd like to coordinate so we can use the same wrapper scripts, plugins, etc.

You read my mind!

I am working on a 'super' source package.  Here is an example source tree.

netscape-browser
|-- libc6
|   |-- communicator.tar.gz
|   `-- navigator.tar.gz
|-- libc5
|   |-- communicator.tar.gz
|   `-- navigator.tar.gz
`-- debian
| rules
| .. etc ..
|-- netscape-browser-base/
|-- communicator-libc5-smotif/
|-- communicator-libc6-smotif/
|-- communicator-libc5-dmotif/
|-- communicator-libc6-dmotif/
|-- navigator-libc5-smotif/
|-- navigator-libc6-smotif/
|-- navigator-libc5-dmotif/
|-- navigator-libc6-dmotif/
|-- netscape-java/
|-- netscape-installer/
|-- communicator-nethelp/
|-- navigator-nethelp/
`-- movemail/

I have already looked at and compared the java portions of the tarballs, and 
the .jar files are the same.  I am just trying to think how I would want them
placed in the fs.  I am leaning toward /usr/lib/netscape/java

I have already scrapped the ns-install file, and written my own, so that I
don't have to do any moving of files in debian/rules.  I call it as:
'my-install -t  -p  -p  -p  ...'  Pkg can also be
'all.'

Also, another point I am worried about.  Included in the tarballs are hooks
into an automated software update mechanism.  I have that disabled, as that
would not fit well with the debian way of maintaining things.  Anyone else
have ideas on this?

Adam



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

Re: Upgrading from bo to hamm

[LeRoy D. Cressy]

Guy Maor wrote:
> 
> "LeRoy D. Cressy" <[EMAIL PROTECTED]> writes:
> 
> > I question the purpose of leaving broken symbolic links when
> > upgrading the libraries.  For instance libreadline2 leaves
> > the following broken links reported by ldconfig:
> 
> Those symlinks are part of libreadline2-dev.  If you upgrade to
> libreadline2-altdev, then the links will be fixed.

I realize that when you upgrade the *-altdev libraries in the 
oldlibs directory will fix the errors, but what I am suggesting
across the board is that is an updated package breaks some
symbolic links, then the post install script should run 
symlinks -d on the /lib and the /usr/lib directories prior to
running ldcongig.  

This approach will help everyone when upgrading their bo system 
to a hamm system.  

I am not just asking for an immediate fix, but proposing a
method that will not return error messages that might scare the
novice that is attempting to upgrade their system.

Without these measures installed, a novice that will attempt to use 
dselect to upgrade his or her system could really break their existing
system.  This ought not to be.

Enough preaching for now,
Have a great day :-)
-- 
  0 0  L & R Associates
   "   Home Page:http://www.netaxs.com/~ldc/
___ooO ~ Ooo___

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


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

Re: Is this a bug in libc6?

[Avery Pennarun]

On Sat, 11 Apr 1998, Steve Greenland wrote:

> >  BTW, in Debian, fclose says it returns an error, and does not mention
> >  corrupting memory. 
> > ERRORS
> >EBADF  The argument stream is not an open stream.
> > 
> >The fclose function may also fail and set errno for any of
> >the  errors  specified  for  the  routines   close(2)   or
> >fflush(3).
> 
> Oh, sure, that's an error it *may* report, *if* it detects it. I don't
> see anything on the man page that would expect me to believe that the
> implementation will detect all possible invalid streams and report an
> error. I am also quite willing to believe that the particular error we
> are discussing (fclose(fp);fclose(fp)) will be detected.

The point here is that it's _documented_ to return EBADF if the stream
pointer is not an open stream, and that's not what happens.  This is
difficult to enforce in practice, and is not necessary for ISO compliance --
so let's fix the man page.

Has anyone submitted a bug against manpages yet?

Avery


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

Re: dpkg memory usage

[Steve Dunham]

John Goerzen <[EMAIL PROTECTED]> writes:

> I was upgrading packages on my 64 meg system today ant noticed:

>   PID USER PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
> 24785 root  18   0 12680  12M   568 S   0  0.1 20.0   5:36 dpkg

> Yes, that's almost 13 megs used by dpkg, and 20% of my RAM.

> That also is 4 megs more than the TOTAL amount of RAM in some computers I
> work with.

> So...why must dpkg use almost as much memory as XFree86 itself, and MORE
> than Netscape does at times?

> Not only that, but it is hideously slow even on current computers.  My
> suggestion: store the databases in a DBM format of some sort instead of
> plain text. 

IMHO, dpkg should be using a DBM database for file -> package lookups
and perhaps for the "status" and "available" caches too.  (I believe
apt does something like this for "available".)

(I presume that dpkg actually does use hash tables internally, but it
recalculates that 12MB of data everytime it starts up, which, IMHO, is
not very efficient.)

The startup time and memory usage is just not worth any benefits
gained from using a few thousand text files.  

And the text version is still prone to severe corruption.  Mine was
scrambled the other day when I upgraded the modutils package running a
2.1.x kernel - the machine locked up, and when I rebooted and tried to
install more packages, dpkg mixed up a bunch of scripts and .list
files.


Steve
[EMAIL PROTECTED]


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

bind bugfix for bo

[Gergely Madarasz]

Hello!

A bind security fix package has just bin installed into bo-unstable. It
is version 8.1.2-0.bo1. If you are using bind 4.9.x you should seriously
consider upgrading.

Greg

--
Madarasz Gergely   [EMAIL PROTECTED] [EMAIL PROTECTED]
  It's practically impossible to look at a penguin and feel angry.
  Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
  HuLUG: http://www.cab.u-szeged.hu/local/linux/


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

Re: Is this a bug in libc6?

[Manoj Srivastava]

Hi,
>>"Steve" == Steve Greenland <[EMAIL PROTECTED]> writes:

Steve> On 11-Apr-98, 02:26 (CDT), Manoj Srivastava
Steve> <[EMAIL PROTECTED]> wrote:
>> So, the point is not whether they implemntation can do strange and
>> unexpected things; they can; but then they have to document it.
>> 
>> BTW, in Debian, fclose says it returns an error, and does not
>> mention corrupting memory.  ERRORS EBADF The argument stream is not
>> an open stream.
>> 
>> The fclose function may also fail and set errno for any of the
>> errors specified for the routines close(2) or fflush(3).

Steve> Oh, sure, that's an error it *may* report, *if* it detects
Steve> it. I don't see anything on the man page that would expect me
Steve> to believe that the implementation will detect all possible
Steve> invalid streams and report an error. I am also quite willing to
Steve> believe that the particular error we are discussing
Steve> (fclose(fp);fclose(fp)) will be detected.

Fair enough. In which case this should be documented.

Steve> Unfortunately, that belief is not supported. 

Then this is a defect in the implementation.

manoj
-- 
 There are two ways to improve on human factors in computing: Make the
 programmers less stupid and/or make the users less stupid.  Both are
 necessary, neither are likely.  Digital Teddy Bear
 ([EMAIL PROTECTED])
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: Is this a bug in libc6?

[Manoj Srivastava]

Hi,
>>"Kai" == Kai Henningsen <[EMAIL PROTECTED]> writes:

Kai> Bullshit.

Bullshit? And this is supposed to be a technical discussion?
 Can you not engage in civilized discourse without resorting to
 invective? Do you realize that is generally the case with a weak
 argument?

Kai> The documentation requirement is for implementation-defined
Kai> behaviour. For undefined behaviour, "the standard imposes no
Kai> requirements". No requirements are no requirements. There is no
Kai> requirement that such an action is documented.

Have you actually read the standard? I even quoted parts of
 IEEE 1.6 for you. I shall do so again.

--
1.6 Definitions of terms

o Undefined Behaviour -- behaviour, upon the use of a nonportable or
  erroneous program construct, of erroneous data, or of inderminately
  valued objects, for which the standard imposes no
  requirements. Permissible undefined behaviour ranges from ignoring
  the situation completely with unpredictable results, to behaving
  during translation or program execution in a documented manner
  charecteristic of the environment (with or without the issuance of a
  diagnostic message), to terminating a translation or execution (with
  the issuance of a diagnostic message).

If a "shall" or "shall not" requirements that appears outside
 of a constraint is violated, the behaviour is undefined. Undefined
 behaviour is otherwise indicated in this standard by the words
 "undefined behaviour" or by the omission of any explicit definition
 of behavior. There is no difference in emphasis among these three;
 they all describe "behaviour that is undefined."

o Unspecified behaviour -- behaviour, for a correct program construct
  and correct data, for which the standard explicitly imposes no
  requirements.

__


See where it says "Permissible undefined behaviour"?  Ignoring
 the second fclose completely (which may have unpredictable results),
 "behaving during translation or program execution in a documented
 manner charecteristic of the environment", or terminating (in which
 case an error message is required: anything else is a violation of
 the standard. Period.

All under "Permissible undefined behaviour".

And yet you use invective and state things in direct
 contradiction of the standard.

Kai> Undefined is *un*defined.

Oh, despite what the standard says, if you say it is
 undefined, it is undefined. Wonderful. 

Kai> The only interesting question here is if fclose(fp); fclose(fp);
Kai> is indeed undefined. (Note that fp=fopen("not.there", "r");
Kai> fanything(fp); is undefined simply because fp is NULL.) I suspect
Kai> it is, because after the first fclose(fp); it has "indeterminate
Kai> value".

Quite so.

manoj
-- 
 "If the conjecture `You would rather I had not disturbed you by
 sending you this.' is correct, you may add it to the list of
 uncomfortable truths." Edsgar Dijkstra
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: Debian Bug#20445 disagree

[Marcus Brinkmann]

On Sat, Apr 11, 1998 at 01:16:19PM -0400, Brian White wrote:
> > > > Also, how likely are the current versions of these programs
> > > > to work with future versions of the unstable 2.1 kernel and the 2.2
> > > > kernel that will eventually come from it?
> > 
> > True enough. But a Debian 2.1.x package and packages that works with it
> > could be good for seeing and trying out. So you know what debian packages
> > there are and what they provide before you even switch on your modem.
> > 
> > OTOH, we don't have a kernel-source package for hamm.
> > 
> > So you have made your point, as I have made mine.
> 
> Okay, how about this...
> 
> 2.1 kernel-requiring stuff (and a current 2.1 kernel?) can be included
> under "contrib".  This keeps it out of "main" and puts it into the realm
> of "user-beware".  (Note:  This is not to insinuate that everything in
> contrib is dangerous or anything, but just that you should think at least
> once before installing it.)

I'm not sure how many people think about contrib (I seldom look at the section
when installing software, well, I get suspicious if it is non-free), and it
doesn't quite meet the definition of contrib (more the spirit of extra),
but if you think it is appropriate...

IMO it could even go in a not-dselectable directory on the CD, not listed
in any package file at all. A developer would know where to look, and it
could be mentioned in a readme.new-kernel.

> Acceptable?

Sure. My only interest is that a 2.1.x kernel is on the CD ;) And I would
not start fighting around for it...

Thank you,
Marcus

-- 
"Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ 
Marcus Brinkmann   http://www.debian.orgmaster.debian.org
[EMAIL PROTECTED]for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   PGP Key ID 36E7CD09


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

Re: Is this a bug in libc6?

[Manoj Srivastava]

Hi,
>>"Kai" == Kai Henningsen <[EMAIL PROTECTED]> writes:

Kai> [EMAIL PROTECTED] (Manoj Srivastava) wrote on 11.04.98 in
Kai> <[EMAIL PROTECTED]>:
>> Look at the whole sentence, please. There are indeed no
>> requirements for the program to behave in any fashion; as long as
>> the

Kai> No. There are no requirements, period. Look at the sentence
Kai> yourself.

Permissible undefined behaviour ranges from ignoring the
situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
charecteristic of the environment (with or without the
issuance of a diagnostic message), to terminating a
translation or execution (with the issuance of a diagnostic
message).

Seems like a requirement to me, or else it is not permitted
 undefined behaviour. Tell me how fclose in Debian does not volate
 this from 1.6 of the standard (IEEE versioning).

>> I know fashionable, but incorrect, comments on comp.lang.c would
>> have it otherwise.

Kai> It is interesting to note that *all* members of the committee
Kai> that wrote this standard that have ever spoken up on comp.std.c,
Kai> have agreed with these "fashinable comments".

I do not care. Even technically competent people make mistakes
 while expressing personal opinion.  I am looking, instead of
 comp.lang.c, to the IEEE/ISO/IEC standard. I still submit the
 standard is a better authority thatn the USENET. (You must admit the
 comments about monkeys, first made by Chris Torek, was made under
 frustation and extreme provocation; and was meant more to drive the
 lesson home that to be an interpretation of the standard).

manoj

-- 
 "We are not endeavoring to chain the future but to free the
 present. ... We are the advocates of inquiry, investigation, and
 thought. ... It is grander to think and investigate for yourself than
 to repeat a creed. ... I look for the day when *reason*, throned upon
 the world's brains, shall be the King of Kings and the God of Gods."
 Robert G. Ingersoll
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: Upgrading from bo to hamm

[LeRoy D. Cressy]

Steve Greenland wrote:
> 
> On 09-Apr-98, 22:04 (CDT), Guy Maor <[EMAIL PROTECTED]> wrote:
> > "LeRoy D. Cressy" <[EMAIL PROTECTED]> writes:
> >
> > > I question the purpose of leaving broken symbolic links when
> > > upgrading the libraries.  For instance libreadline2 leaves
> > > the following broken links reported by ldconfig:
> >
> > Those symlinks are part of libreadline2-dev.  If you upgrade to
> > libreadline2-altdev, then the links will be fixed.
> 
> There's the general problem that library symlinks aren't removed when
> the library is removed, thus leading to a buildup of "file not found"
> messages from ldconfig until I get tired of them and clean them out.
> Removing a library should remove all the symlinks as well.
> 
> I'm not sure whether this is in fact the way it supposed to work, and
> it's just that I continually run into buggy packages, or whether this is
> something that needs to be added to policy (I guess I should go read the
> policy manual to see what it says...).
> 
> Steve
>

Thanks Steve for taking the time to read what I was actually saying.

I feel that this is a problem that should be addressed across the
board when removing libraries and files.  Leaving dangling links
until the development portion of the library is upgraded is a BAD
idea

Have a great day :-)
-- 
  0 0  L & R Associates
   "   Home Page:http://www.netaxs.com/~ldc/
___ooO ~ Ooo___

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


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

Re: Bug#20514: tetex-base: Much documentation missing.

[Christoph Martin]

Karl M. Hegbloom writes:
 > Package: tetex-base
 > Version: 0.9-4
 > Severity: Wishlist
 > 
 >  Will you please ftp the `ntex' distribution from sunsite and look
 > through the documentation that is shipped with it, and see if any can
 > be added to the tetex distro? ;-)
 > 
 >

Can you please assemble a list of files which should be aaded to the
debian distribution.

If someone volunteers to build a package out of it, I would be
thankfull. I'm busy in buiding the main tetex packages.

Christoph


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

Re: Debian Bug#20445 disagree

[Brian White]

> > 2.1 kernel-requiring stuff (and a current 2.1 kernel?) can be included
> > under "contrib".  This keeps it out of "main" and puts it into the realm
> > of "user-beware".  (Note:  This is not to insinuate that everything in
> > contrib is dangerous or anything, but just that you should think at least
> > once before installing it.)
> 
> I'm not sure how many people think about contrib (I seldom look at the section
> when installing software, well, I get suspicious if it is non-free), and it
> doesn't quite meet the definition of contrib (more the spirit of extra),
> but if you think it is appropriate...

I was thinking "project/experimental" would be better, but I don't think
that goes out on many CDs.

  Brian
 ( [EMAIL PROTECTED] )

---
 Generated by Signify v1.04.  For this and more, visit http://www.verisim.com/



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

Re: Debian Bug#20445 disagree

[Marcus Brinkmann]

On Sat, Apr 11, 1998 at 03:18:46PM -0400, Brian White wrote:
> 
> I was thinking "project/experimental" would be better, but I don't think
> that goes out on many CDs.

>From a logical point of view, I think project/experimental is the best
choice. Why don't we include selected directories from there on the official
CD (I think of gettext (ouch, don't beat me), 2.1.x software, ...)?

Great idea Brian,
Marcus

-- 
"Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ 
Marcus Brinkmann   http://www.debian.orgmaster.debian.org
[EMAIL PROTECTED]for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   PGP Key ID 36E7CD09


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

Re: Is this a bug in libc6?

[Gregory S. Stark]

Manoj Srivastava <[EMAIL PROTECTED]> writes:
>   Permissible undefined behaviour ranges from ignoring the
>   situation completely with unpredictable results, to behaving
>   during translation or program execution in a documented manner
>   charecteristic of the environment (with or without the
>   issuance of a diagnostic message), to terminating a
>   translation or execution (with the issuance of a diagnostic
>   message).
> 
>   Seems like a requirement to me, or else it is not permitted
>  undefined behaviour. Tell me how fclose in Debian does not volate
>  this from 1.6 of the standard (IEEE versioning).

No it's not a requirement. Requirements are stated in the for "the
implementation shall" or "the implementation must", not "permissable behaviour
ranges from ... to ...". First of all the latter phrasing doesn't say anything
about whether other behaviour is premissable, and second who's to say what
falls between the three stated points in the "range" or what constitutes
"unpredictable results".

What has happened here is that gnu libc has chosen the first choice. Failing
to check the input and print a diagnostic message or exit, it completely
ignored the situation. The "unpredictable results" (or not so unpredictable
really) was that the program received a SEGV.

Experience shows checking arguments is not usually hard or expensive and I
would support suggesting the glibc people change this behaviour. But it's
certainly permissable under ISO to not do so. Thanks for quoting the spec so
we can all verify that it explicitly allows the implementation to not check.

>  (You must admit the comments about monkeys, first made by Chris Torek, was
>  made under frustation and extreme provocation; and was meant more to drive
>  the lesson home that to be an interpretation of the standard).

If this conversation goes on much longer i'll be in a similar state soon.


greg


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

Re: Is this a bug in libc6?

[Steve Greenland]

On 11-Apr-98, 13:27 (CDT), Avery Pennarun <[EMAIL PROTECTED]> wrote:
> The point here is that it's _documented_ to return EBADF if the stream
> pointer is not an open stream, and that's not what happens.  This is
> difficult to enforce in practice, and is not necessary for ISO compliance --
> so let's fix the man page.

Nope, you're reading that backwards. It says that if fclose() returns
_EOF_ and _errno_ = _EBADF_, then that means that the stream is not
open.

Steve


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

Question on copyright

[Bart Warmerdam]

Hi,

I am currently enhancing my sound recorder to handle compressed wave
formats. To implement msadpcm (Microsoft implementation) i used the
examples as provided by them. This carries the following notice:

/** msadpcm.c
 *
 (C) Copyright Microsoft Corp. 1993.  All rights reserved.

 You have a royalty-free right to use, modify, reproduce and
 distribute the Sample Files (and/or any modified version) in
 any way you find useful, provided that you agree that
 Microsoft has no warranty obligations or liability for any
 Sample Application Files which are modified.

 If you did not get this from Microsoft Sources, then it may not be the
 most current version.  This sample code in particular will be updated
 and include more documentation.
*/

Does this copyright on the examples cause any problems to GPL my source
(i think not) and what notices are needed?
The player with this part will become part of my debian package
sound-recorder.

Thanks,

Bart


pgpc6EbNs2gIy.pgp
Description: PGP signature

Re: Is this a bug in libc6?

[Manoj Srivastava]

Hi,
>>"Gregory" == Gregory S Stark <[EMAIL PROTECTED]> writes:

Gregory> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> Permissible undefined behaviour ranges from ignoring the situation
>> completely with unpredictable results, to behaving during
>> translation or program execution in a documented manner
>> charecteristic of the environment (with or without the issuance of
>> a diagnostic message), to terminating a translation or execution
>> (with the issuance of a diagnostic message).
>> 
Gregory> No it's not a requirement. Requirements are stated in the for
Gregory> "the implementation shall" or "the implementation must", not
Gregory> "permissable behaviour ranges from ... to ...".

I think I disagree here. I think both should be followed by
 implemntations. What is the point of having a permissible behaviour
 defined in the standard otherwise?

Gregory> First of all the latter phrasing doesn't say anything about
Gregory> whether other behaviour is premissable, and second who's to
Gregory> say what falls between the three stated points in the "range"
Gregory> or what constitutes "unpredictable results".

I interpret this to mean that *all* permissible undefined
 behaviour has to fall in the categories listed, and the whole range
 is explicitly defined in the sentence. "Unpredictable results" is not
 constrained by the standard, except that it be documented and be a
 "characteristic of the environment."


Gregory> What has happened here is that gnu libc has chosen the first
Gregory> choice. Failing to check the input and print a diagnostic
Gregory> message or exit, it completely ignored the situation. The
Gregory> "unpredictable results" (or not so unpredictable really) was
Gregory> that the program received a SEGV.

It still has to document the behaviour.

Gregory> Experience shows checking arguments is not usually hard or
Gregory> expensive and I would support suggesting the glibc people
Gregory> change this behaviour. But it's certainly permissable under
Gregory> ISO to not do so. Thanks for quoting the spec so we can all
Gregory> verify that it explicitly allows the implementation to not
Gregory> check.

I think I disagree here. 

>> (You must admit the comments about monkeys, first made by Chris
>> Torek, was made under frustation and extreme provocation; and was
>> meant more to drive the lesson home that to be an interpretation of
>> the standard).

Gregory> If this conversation goes on much longer i'll be in a similar
Gregory> state soon.

Quite so. This is way off topic for this list now, and should
 be taken to personal email.

manoj

-- 
 "I have often thought that if there had been a good rap group around
 in those days I might have chosen a career in music instead of
 politics." Richard Nixon
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: Question on copyright

[Ben Pfaff]

   /** msadpcm.c
*
(C) Copyright Microsoft Corp. 1993.  All rights reserved.

You have a royalty-free right to use, modify, reproduce and
distribute the Sample Files (and/or any modified version) in
any way you find useful, provided that you agree that
Microsoft has no warranty obligations or liability for any
Sample Application Files which are modified.

If you did not get this from Microsoft Sources, then it may not be the
most current version.  This sample code in particular will be updated
and include more documentation.
   */

   Does this copyright on the examples cause any problems to GPL my source
   (i think not) and what notices are needed?

It doesn't mention that any notices are necessary; however you should
include this notice in the /usr/doc//copyright file.  It's
pretty scary that we're using code from the Evil Empire, but in
practical terms, it's irrelevant.

   The player with this part will become part of my debian package
   sound-recorder.


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

Re: Is this a bug in libc6?

[Avery Pennarun]

> > The point here is that it's _documented_ to return EBADF if the stream
> > pointer is not an open stream, and that's not what happens.  This is
> > difficult to enforce in practice, and is not necessary for ISO
> > compliance -- so let's fix the man page.
> 
> Nope, you're reading that backwards. It says that if fclose() returns EOF_
> _and _errno_ = _EBADF_, then that means that the stream is not
> open.

You people are being unbelievably pedantic.

I know I'm not supposed to fclose() an already-closed stream, or one that
failed to fopen().  If I try that, I _expect_ unpredictable behaviour!

However, when I read the manpage, I found it quite unclear.  If I didn't
know better, I would think that double-fclose()ing a file was okay.

The bug is not in libc, it's in the manpage.  Fix the manpage.

Avery


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

Re: sleep contains crypto stuff?

[Marcelo E. Magallon]

On Sat, 11 Apr 1998, Martin Schulze wrote:

> Apart from that, I thought that gcc and tools are intelligent
> enough to only link routines and libraries to executables if
> there are routines from them used.

They are not. I pointed this out on debian-policy a while ago,
but nobody seemed to care. :-(


Marcelo


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