Bug#386214: manpages-dev: clog10 logarithm formula shown
On Wed, Sep 06, 2006 at 02:50:36PM +0200, Michael Kerrisk wrote: > tags 386214 fixed-upstream > thanks > > Kevin, > DESCRIPTION >The call clog10(z) is equvalent to clog10(z)/log(10). "Is equivalent to clog(z)/log(10)" Andries -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#2387: Processed: Re: Manpage gethostbyaddr
On Sun, May 21, 2006 at 12:17:31PM -0400, Justin Pryzby wrote: > Hello Andries, > > That message was actually not automated; Michael subscribes to the > package, so he will have gotten an email too. > > FYI the relevant bug log can be seen at: > > http://bugs.debian.org/2387 > gethostbyaddr(3) ill documented > (and there is a bug requesting that a URL be included in the ACK > messages, but that is irrelevant here). > > Justin That the bug is still present shows a weakness in the Debian bug handling system. Formalities are handled, but no actual work is done. Did anyone read the report? Read the report. It is from 1997. It says two things: (i) why is the prototype what it is? (ii) please document the use of the first argument. Part (i) is not to be addressed by the manpage maintainer. The prototype is given by POSIX, or given by glibc, but certainly not determined by the manpage author. He just documents. Part (ii) very much is the job of the manpage maintainer. And he did his job - details have been added, the current text is much more precise than that of 1997. So, there is nothing to do. Andries -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#197004: Forwarded Debian bug reports about "wrong fs type" error message
On Sun, Jan 22, 2006 at 09:52:34PM +0100, Josip Rodin wrote: > I don't think this would be that much worse But I think it would be worse. That is why I didnt do it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#197004: Forwarded Debian bug reports about "wrong fs type" error message
On Sun, Jan 22, 2006 at 02:05:08PM +0100, Josip Rodin wrote: > And besides, how hard is it to cache a warning message about non-existent > mount.$fstype and display it a few lines below if the EINVAL happens? You see, it would not be an improvement at all. Someone tries to mount a CDROM and gets "mount.iso9660 not found". She will be very confused. Do I need that? Such an error message will point people to something that almost certainly is not the cause of the problem. Giving useful error messages is difficult, but mount tries. In this case the suggested change would not be an improvement. Andries -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#197004: Forwarded Debian bug reports about "wrong fs type" error message
On Sat, Jan 21, 2006 at 05:34:41PM +0100, Josip Rodin wrote: > I'm sorry? How exactly am I clueless? You forgot to RTFM. > You think it's normal for mount to ignore the fact that > mount.$fstype is ENOENT when mount() returned EINVAL? Yes. Read mount(8) and see: Mount options for smbfs Just like nfs, the smbfs implementation expects a binary argu- ment (a struct smb_mount_data) to the mount system call. This argument is constructed by smbmount(8) and the current version of mount (2.12) does not know anything about smbfs. That shows that mount is the wrong program to call. But if you call it anyway, and you have mount.smbfs in place, mount will invoke that, and things still work. You will also find that if you search the manpage for the string smbfs. The normal situation is that mount.$fstype returns ENOENT. It is normal that there is no mount.$fstype - this is almost never an error. If there is no special mount program for some type then mount will do the generic mount call, and report on error returns it gets from those. It would be a mistake to build into mount knowledge about all of the different filesystems - it is bad enough that it knows about nfs. So, the reporting from mount is generic, not filesystemtype-specific. If there are problems for one particular type, then read the docs and do dmesg | tail etc. Andries -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328269: manpages-dev: rand() manpage misrepresents FreeBSD's sranddev()
On Tue, Sep 20, 2005 at 02:34:37AM +0200, Hrvoje Niksic wrote: > I have provided arguments for my position, to which you failed to > respond. You didn't give any reasons why you consider FreeBSD to be > "very similar" to Linux No response is needed. If you do not understand that the specific implementation is irrelevant for the man page author, and that tne APIs in FreeBSD and Linux are very similar then discussion with you is not interesting. > Better yet, the limited space available in a man page should be spent > documenting the API Linux does support. For example, it could mention > that RAND_MAX is not 32767, unlike many other systems. It could > mention that RAND_MAX+1 causes an overflow on Linux, breaking poorly > written code. It could mention that rand(3) should *never* be used > for cryptographic purposes. It could mention that standard library > functions do not influence the sequence of numbers returned by rand. > It could document the period of the random number generator, or that > ISO C requires the period to be at least 2**32, if the period is > considered an implementation detail and not part of the API. Some of these remarks could indeed be added to the manual page. Submit a patch. Be careful to distinguish Linux-specific remarks (dependency on Linux kernel) from libc-specific remarks (dependency on libc or glibc or klibc or uClibc etc.) and remarks about standard requirements, and general remarks (like remarks about what is needed for crypto). Be concise and precise. Yes, the period is an implementation detail - the current glibc implementation has a much larger period than the classical Unix version. Classically rand() is bad and random() is much better but for glibc the two are the same. RAND_MAX is 2^31-1 in current glibc, and already had that value in libc4. Andries -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328269: manpages-dev: rand() manpage misrepresents FreeBSD's sranddev()
On Tue, Sep 20, 2005 at 12:39:55AM +0200, Hrvoje Niksic wrote: [muttering that he does not want to hear about differences between the FreeBSD and the Linux API for the rand() family of functions; don't know why - I always consider info about differences important] But now that I see my text again, let me add one letter and change it into "FreeBSD adds a function void sranddev(void); that initializes the seed for rand() with a value obtained from the /dev/urandom device." making it more correct for FreeBSD, DragonflyBSD, MacOS X. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328269: manpages-dev: rand() manpage misrepresents FreeBSD's sranddev()
On Mon, Sep 19, 2005 at 07:35:30PM +0200, Hrvoje Niksic wrote: > Andries Brouwer <[EMAIL PROTECTED]> writes: > > > This can be replaced by > > > > "FreeBSD adds a function > > void sranddev(void); > > that initializes the seed for rand() with a value obtained from > > the /dev/random device." > > But why waste space on functions on other operating systems that Linux > doesn't have? All Unix-like operating systems are rather similar. It is better to describe the Linux situation and mention the differences with other very similar systems than to just give the Linux description. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#326720: carg(3) man page error
On Mon, Sep 19, 2005 at 02:04:00PM +0200, Michael Kerrisk wrote: > Andries, > > Could you comment on the following please -- I don't remember > enough of my maths... > > Cheers, > > Michael Ramiro is right - that is, his text is much better than the present text. However normalizations differ. It is true that tan(carg(z)) = cimag(z) / creal(z), almost by definition. Taking atan() on both sides yields atan(tan(carg(z))) = atan(cimag(z) / creal(z)) but it is not precisely true that atan(tan(x)) = x. The tan() function is periodic with period pi, and atan() returns an answer in (-pi/2,pi/2], so atan(tan(x)) returns the value that is congruent x mod pi and lies in this interval. In particular, atan(tan(carg(z))) returns a value that is congruent carg(z) mod pi and lies in (-pi/2,pi/2]. On the other hand, carg returns a value in [-pi,pi] and if that return value does not lie in (-pi/2,pi/2] then carg(z) and atan(cimag(z) / creal(z)) will differ by pi. In other words: you may write "One has tan(carg(z)) = cimag(z) / creal(z)." Andries >> Von: Ramiro Aceves <[EMAIL PROTECTED]> >> An: [EMAIL PROTECTED] >> Betreff: Bug#326720: carg(3) man page error >> Datum: Mon, 05 Sep 2005 12:19:14 +0200 >> >> Package: manpages-dev >> Version: 1.70-1 >> >> There seems to be en error in carg(3) man page, DESCRIPTION chapter. >> >> "One has carg(z) = atan(creal(z) / cimag(z))" >> >> is wrong and should be : >> >> "One has carg(z) = atan(cimag(z) / creal(z))" >> >> Hope this helps. >> >> Thank you very much. >> >> Ramiro. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328269: manpages-dev: rand() manpage misrepresents FreeBSD's sranddev()
On Mon, Sep 19, 2005 at 02:58:24PM +0200, Michael Kerrisk wrote: > [Andries Brower CCed since he may have written the original text] > > > Package: manpages-dev > > Version: 2.02-2 > > Severity: minor > > > > Man page for rand(3) claims the following: > > > >FreeBSD adds a function > > > > void sranddev(void); > > > >that initializes the seed for their bad random generator rand() > >with > >a value obtained from their good random generator random(). > >Strange. This can be replaced by "FreeBSD adds a function void sranddev(void); that initializes the seed for rand() with a value obtained from the /dev/random device." Andries -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
