Bug#380609: konsole: prompt bold-printing no longer works
I no longer see this bug in konsole 4:3.5.5a-2. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391402: manpages-dev: Misleading wording regarding strcmp as the comparison routinein qsort
Package: manpages-dev Version: 2.39-1 Severity: minor The qsort(3) man page seems to imply that strcmp can be passed as a comparison routine to qsort. The sentence I refer to is: Library routines suitable for use as the _compar_ argument include strcmp() (see below), alphasort(), and versionsort(). As written, the sentence is self-contradictory: it (falsely) claims that strcmp is suitable for use as the _compar_ argument, and then refers the reader to the example which (correctly) explains that this is not the case. Since strcmp really cannot be used as _compar_, I propose to change the sentence. I believe the intention of mentioning strcmp there was to say that strcmp is useful for *implementing* a comparison function, and that intention is worth retaining. That is why I propose the sentence to be changed to something like: Library routines suitable for use as the _compar_ argument include alphasort() and versionsort(). To compare C strings, the comparison function can call strcmp(), as shown in the example below. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages manpages-dev depends on: ii manpages 2.39-1 Manual pages about using a GNU/Lin manpages-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380609: konsole: prompt bold-printing no longer works
Please note that this bug occurs not only for bold printing of shell prompts, but for any bold text in the terminal. For example: $ printf 'bold test: \033[1mbold on\033[m bold off\n' shows bold on in bold typeface on terminal emulators other than the latest konsole. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386730: zsh: printf doesn't handle single-digit and two-digit octal escapes
Package: zsh Version: 4.3.2-14 Severity: normal zsh's builtin printf fails to interpret two-digit octal escape, such as '\1' or '\33'. For example: zsh% printf '\33abc' | hd 5c 33 33 61 62 63 |\33abc| 0006 On the other hand, the printf from textutils handles them: $ /usr/bin/printf '\33abc' | hd 1b 61 62 63 |.abc| 0004 The zshbuiltins man page promises formatting rules are the same as used in C, and C explicitly supports single-digit and double-digit octal escapes in string and character literals -- see section 6.4.4.4 Character constants of the C99 standard. Furthermore, POSIX explicitly states that \d and \dd are supported by printf(1) -- see http://tinyurl.com/gkdfr/, extended description, item 3. The Solaris printf(1), the bash printf builtin, and the FreeBSD printf(1) all support them. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages zsh depends on: ii debconf [debconf-2.0]1.5.3 Debian configuration management sy ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libncurses5 5.5-2 Shared libraries for terminal hand Versions of packages zsh recommends: ii libcap1 1:1.10-14 support for getting/setting POSIX. ii libpcre3 6.4-2 Perl 5 Compatible Regular Expressi -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377200: strace: Breaks multithreaded program with -f -p pid
Package: strace
Version: 4.5.14-1
Severity: normal
If you attach to a running multithreaded program using -f -p pid,
everything seems to work fine (you get the trace of all running threads)
until the time comes to detach. Pressing ^C leaves strace hanging; pressing
^Z followed by kill %1 kills strace, but also kills the traced program.
This makes strace useless for tracing running multithreaded programs.
To repeat:
$ pgrep firefox
3422
$ strace -fp 3422
... a bunch of output ...
[pid 3422] gettimeofday({1152268503, 354598}, NULL) = 0
[pid 3422] poll(^CProcess 3422 detached
At this point, strace is hanging. When I press ^Z and kill strace, Firefox
dies as well. The same happens with other multithreaded programs, not just
Firefox. The problem does not occur without -f and therefore is not an
issue for single-threaded programs.
This is under Debian's 2.6.15-1-686 kernel, but the same seems to happen
under other kernels from the 2.6 series.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (900, 'testing'), (800, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages strace depends on:
ii libc6 2.3.6-15 GNU C Library: Shared libraries
strace recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373833: xbase-clients: hr(us) layout apparently broken
Vedran Furač [EMAIL PROTECTED] writes: Inserting 'include us' after the 'name[Group1]= Croatia - US keyboard with Croatian letters;' line fixes the problem for me. Try that and see if it helps. That fixes the problem, thanks. The fix is obvious in retrospect, especially given that I inspected the ubuntu version of the file, which had the include line; I don't know how I missed it.
Bug#373833: xbase-clients: hr(us) layout apparently broken
Package: xbase-clients
Version: 1:7.0.1-2
Severity: normal
The hr(us) layout appears completely broken in the current X server in
testing. While the command `setxkbmap hr us' does not report an error, it
leaves the keyboard in an unusable state: all ASCII characters, such as
letters, numbers, and ASCII symbols are unavailable. Arrows, function keys,
space, backspace and return are still available, and so are the additional
Croatian characters the layout is supposed to offer! Running `setxkbap us'
correctly restores the keyboard to the US layout. `setxkbmap hr' likewise
works well. I use the kbd keyboard driver, but observed behavior is
identical with both keyboard and kbd.
Some background info: the hr(us) layout is designed to be identical to the
US keyboard layout, but with the Croatian letters available by pressing
AltGr along with the key where the character would be on a Croatian
keyboard. For example, pressing AltGr-; emits ccaron because ccaron is
positioned on ; on a regular Croatian keyboard. This layout is very useful
for programming because it retains syntactical symbols (parentheses, square
and curly braces, slash, backslash semicolons, etc.) at their standard
positions, while allowing full access to Croatian-specific letters without
switching layouts.
The layout used to be known as hr_US in older XFree86 releases, then hr(alt)
for a while in ubuntu, and was finally renamed to hr(us). The file that is
supposed to describe it is /usr/share/X11/xkb/symbols/hr; refer to the
xkb_symbols us { ... } section.
I'm reporting this to xbase-clients because that's where the setxkbmap
command resides. If another package is more appropriate, feel free to
reassign.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (900, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages xbase-clients depends on:
ii libc6 2.3.6-7GNU C Library: Shared libraries
ii libfontconfig12.3.2-5.1 generic font configuration library
ii libfreetype6 2.2.1-2FreeType 2 font engine, shared lib
ii libfs62:1.0.0-3 X11 Font Services library
ii libgl1-mesa-glx [libgl1] 6.4.1-0.4 A free implementation of the OpenG
ii libice6 6.9.0.dfsg.1-6 Inter-Client Exchange library
ii libpng12-01.2.8rel-5.1 PNG library - runtime
ii libsm61:1.0.0-4 X11 Session Management library
ii libx11-6 2:1.0.0-6 X11 client-side library
ii libxau6 1:1.0.0-3 X11 authorisation library
ii libxaw7 1:1.0.1-5 X11 Athena Widget library
ii libxcursor1 1.1.5.2-5 X cursor management library
ii libxext6 1:1.0.0-4 X11 miscellaneous extension librar
ii libxft2 2.1.8.2-5.1FreeType-based font drawing librar
ii libxi61:1.0.0-5 X11 Input extension library
ii libxkbfile1 1:1.0.2-3 X11 keyboard file manipulation lib
ii libxmu6 1:1.0.1-3 X11 miscellaneous utility library
ii libxmuu1 1:1.0.1-3 X11 miscellaneous micro-utility li
ii libxrandr22:1.1.0.2-4X11 RandR extension library
ii libxrender1 1:0.9.0.2-4X Rendering Extension client libra
ii libxss1 1:1.0.1-4 X11 Screen Saver extension library
ii libxt61:1.0.0-5 X11 toolkit intrinsics library
ii libxtrap6 1:1.0.0-3 X11 event trapping extension libra
ii libxtst6 1:1.0.1-3 X11 Testing -- Resource extension
ii libxv11:1.0.1-3 X11 Video extension library
ii libxxf86dga1 2:1.0.0-3 X11 Direct Graphics Access extensi
ii libxxf86vm1 1:1.0.0-4 X11 XFree86 video mode extension l
ii x11-common1:7.0.20 X Window System (X.Org) infrastruc
ii zlib1g1:1.2.3-11 compression library - runtime
xbase-clients recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323099: License of wget.texi: suggest removal of invariant sections
I understand and agree with the reasoning behind removing the GPL as the invariant section; but why also remove the GFDL as an invariant section? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323099: License of wget.texi: suggest removal of invariant sections
Don Armstrong [EMAIL PROTECTED] writes: Summary: The issue with wget.texi is that the GNU GPL is an Invariant Section; since the GNU GPL cannot be modified anyway, this just forces gpl.texi to always be distributed with wget.texi, even when you're just distributing the manual. The GPL text is an integral part of the manual, so just distributing the manual, at least in its current form, implies distributing the GPL in some form. Note that gpl.texi can always be merged into the manual -- in fact, previous revisions of the manual had the GPL text inline. But that (whether the GPL is in a separate file or in wgettexi) is surely just a technical detail. If the point you're making is that someone might want to remove the GPL text from the manual, for example to make it shorter, I guess that's a valid concern. The reason why this poses a problem for Debian is because it requires the GNU GPL to always be included with wget.texi, even when nothing which is actually GPLed is being distributed along with wget.texi. Debian requires that everything that we distribute in main to be modifiable; that is, so modified that it can actually be deleted. I don't understand this objection. Including the text of the GPL in Wget's manual serves the purpose of explaining Wget's copying terms to the user. As such, it seems pertinent regardless of whether Wget is actually distributed along with the manual. If I am misunderstanding your objection, please let me know. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323099: License of wget.texi: suggest removal of invariant sections
Don Armstrong [EMAIL PROTECTED] writes: On Thu, 18 May 2006, Hrvoje Niksic wrote: If the point you're making is that someone might want to remove the GPL text from the manual, for example to make it shorter, I guess that's a valid concern. Yes, that's the issue. I see. But that's still quite different than the issue you describe below, which is about the GPL no longer applying to Wget (as opposed to the issue of the GPL text making the manual too long). Including the text of the GPL in Wget's manual serves the purpose of explaining Wget's copying terms to the user. As such, it seems pertinent regardless of whether Wget is actually distributed along with the manual. To reiterate what you said above, our problem is that the GPL can't be removed at all,[1] even when it's no longer applicable, not that it's being included by wget.texi in the first place. What I don't understand is how the GPL can be no longer applicable, given that it's not possible to change Wget's license. If the copyright holder (in this case the FSF) decided to change the license, surely they could also remove the invariant section? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336354: emacs-goodies-el: please add savehist.el
Peter S Galbraith [EMAIL PROTECTED] writes: It would be nice to be able to activate it using the customize interface, similarly to what I've done with other other file in emacs-goodies-el. Good idea? I agree that that would be nice, but I don't know what is the standard way to present a minor mode variable to custom. I tried playing with :set, but the results were not what I expected. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336354: emacs-goodies-el: please add savehist.el
Peter S Galbraith [EMAIL PROTECTED] writes: Hrvoje Niksic [EMAIL PROTECTED] wrote: Peter S Galbraith [EMAIL PROTECTED] writes: It would be nice to be able to activate it using the customize interface, similarly to what I've done with other other file in emacs-goodies-el. Good idea? I agree that that would be nice, but I don't know what is the standard way to present a minor mode variable to custom. I tried playing with :set, but the results were not what I expected. Can I infer from the following that it now works? Yes. That code is present in the latest version. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336354: emacs-goodies-el: please add savehist.el
Package: emacs-goodies-el Severity: wishlist You might want to add savehist.el, a neat package for persisting minibuffer histories across Emacs invocations. Get it from: http://fly.srk.fer.hr/~hniksic/emacs/savehist.el Note that an older version of savehist is distributed with XEmacs. Also note that savehist will be distributed with GNU Emacs beginning with the next release. In either case, it is probably best to ensure that this version is used in preference to the one installed with (X)Emacs. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336356: emacs-goodies-el: newer htmlize available
Package: emacs-goodies-el Severity: wishlist emacs-goodies-el ships with htmlize version 1.16. The latest version, available from the author's site, is 1.23. There are no incompatible changes, so I recommend to upgrade the version shipped with this package. As usual, the new version is at: http://fly.srk.fer.hr/~hniksic/emacs/htmlize.el -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- 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()
Andries Brouwer [EMAIL PROTECTED] writes: 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. [...] then discussion with you is not interesting. That is dodging the question, and patronizing to boot. You still didn't mention the criteria by which the APIs in FreeBSD and Linux are very similar, and those in e.g. Solaris and AIX are not. All of those aim to follow the same Unix standards, after all, and all have their own additions to those standards. If you do not understand that the specific implementation is irrelevant for the man page author, I understand that very well -- you are misrepresenting my words. -- 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()
Michael Kerrisk [EMAIL PROTECTED] writes: I see two possible ways of dealing with this: 1. s/random()/random(4)/ in the Linux page. 2. Simply remove this text from the page. What do you think? The first possibility doesn't make sense without also removing the deridive adjective strange, because with changed meaning the function is not really all that strange, is it? Also, I don't see why the man page should enumerate random functions from other operating systems which *don't* exist on Linux? Shouldn't there be enough space used up for functions that we *do* have? When such a function is introduced in glibc, by all means document it. In other words, I think #2 would be appropriate. -- 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()
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? -- 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()
Andries Brouwer [EMAIL PROTECTED] writes: But why waste space on functions on other operating systems that Linux doesn't have? All Unix-like operating systems are rather similar. Except this function has no root in Unix tradition, it is a FreeBSD invention not shared by other Unix-like systems. As far as I can tell, it's not even present on other *BSD flavors. It is better to describe the Linux situation and mention the differences with other very similar systems than to just give the Linux description. How is FreeBSD very similar to Linux? It uses an independently-developed C library and an independently-developed kernel. While I agree that it makes sense to describe historical behavior or the differences between Linux and other *widely accepted* solutions, the sranddev function is neither widely accepted by implementations nor widely used by applications. Therefore it has nothing to do in a manpage of a system that doesn't implement it. Documenting functions found on similar systems, but unsupported by and unimplemented on Linux, will cause clutter due to their sheer number. It's a waste of valuable space better spent on function Linux (glibc) *does* implement. -- 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()
Andries Brouwer [EMAIL PROTECTED] writes: 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] 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 and use that as justification for describing functions not supported on Linux. If you include descriptions of completely non-standard functions found on another OS and not present on Linux, then why not also document various of Solaris, AIX or Windows XP specific functions as well? After all, they contribute to info about differences too. The original wording of that paragraph should be an embarrassment to the author (which I don't claim to be you, I really have no idea who wrote that paragraph), who obviously didn't bother to understand the API he was deriding. It would be best if man pages not written by someone who cared to do the necessary research refrained from documenting the differences between Linux and other systems. 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. -- 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()
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 implies that FreeBSD's sranddev() uses the output of random() to seed rand's PRNG. If that were the case, it would indeed be strange, since random(3) is merely an entry point to another generator, which also needs to be seeded, which would make sranddev useless. But that is, of course, not the case. From the FreeBSD manual: The sranddev() function initializes a seed using the random(4) random number device which returns good random numbers, suitable for crypto- graphic use. That makes a lot more sense: sranddev seeds rand's PRNG from the random number *device* which gets entropy from the system's physical interfaces. random(4) referred to here is the random *device* which has nothing to do with the random() *function* (which would be referred to as random(3)). -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages manpages-dev depends on: ii manpages 2.02-2 Manual pages about using a GNU/Lin manpages-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326767: Failure to use return value from realloc (!)
Maybe I'm missing something, but AFAICT Debian's Wget 1.9.1 doesn't need escape_buffer in log.c at all. Wget 1.9.1-12 in stable includes my backport of 1.10's filtering of control characters via the escnonprint function. When I sent the backport to the maintainer, I expected that he would remove the old fix. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319088: wget: off by one when parsing ftp listing.
The latter patch has been applied and should be available in Wget 1.10.1. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#226084: wget: incorrect encoding of local file names with -k
This bug is fixed in Wget 1.10. Thanks for the report. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320148: requests keep-alive though working on single (or the last) file
I believe this bug is fixed in Wget 1.10.1. See http://article.gmane.org/gmane.comp.web.wget.patches/1459 for a patch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324539: libwww-perl: HTTP::Daemon doesn't report keep-alive connection to HTTP/1.0 clients
Package: libwww-perl Version: 5.803-4 Severity: normal When an HTTP/1.0 client requests persistent connections, HTTP::Daemon respects the request, but doesn't indicate to the client that the resulting connection is keep-alive. Assuming the server example from the man page, the conversation looks like this: $ nc mulj 32790 GET /xyzzy HTTP/1.0 Connection: Keep-Alive HTTP/1.1 200 OK Date: Mon, 22 Aug 2005 16:45:53 GMT Server: libwww-perl-daemon/1.36 Content-Type: text/plain Content-Length: 1329 Last-Modified: Mon, 14 Feb 2005 00:36:13 GMT ... contents of /etc/passwd ... [ client hangs waiting for output ] The problem is that the server didn't indicate a persistent connection by sending the appropriate Connection header with the response. This made the HTTP/1.0 client think that the server didn't understand the keep-alive request and it simply read the response until EOF -- which never came. This problem exists with Wget prior to 1.10.1 when interacting with HTTP::Daemon servers. While assuming persistent connections is correct in HTTP/1.1, it is not the case in HTTP/1.0, where persistent connections exist only as an extension that must be explicitly negotiated between and understood by both the client and the server. If the server doesn't respond with the appropriate token, the HTTP/1.0 client must assume that it is talking to a server that doesn't understand persistent connections and behave accordingly. To summarize: when dealing with HTTP/1.0 clients requesting persistent connections, HTTP::Daemon should either include Connection: Keep-Alive in the response or not use persistent connections at all. The former is obviously preferrable. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages libwww-perl depends on: pn libdigest-md5-perlnone (no description available) ii libhtml-parser-perl 3.45-2 A collection of modules that parse ii libhtml-tree-perl 3.18-1 represent and create HTML syntax t ii liburi-perl 1.35-1 Manipulates and accesses URI strin ii perl [libmime-base64-perl]5.8.7-3Larry Wall's Practical Extraction ii perl-modules [libnet-perl]5.8.7-3Core Perl modules Versions of packages libwww-perl recommends: pn libcompress-zlib-perl none (no description available) pn libhtml-format-perl none (no description available) ii libmailtools-perl 1.62-1 Manipulate email in perl programs -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322913: tcc: _Bool exists but doesn't comply with C99
Package: tcc
Version: 0.9.23-1
Severity: normal
Tcc doesn't correctly implement casts from floating point types to _Bool.
According to C99, such casts must return true for all numbers except 0:
When any scalar value is converted to _Bool, the result is 0 if the value
compares equal to 0; otherwise, the result is 1.
This means that (_Bool) 0.1 must be 1; with tcc it's 0. The following
trivial program can be used to test this:
#include stdio.h
int
main (void)
{
printf (%d\n, (_Bool) 0.1);
return 0;
}
The program prints 1 under Gcc (and other C99-compliant compilers I tested
it with, such as Sun's cc) and 0 under Tcc. I know that Tcc doesn't aim for
C99 conformance, but it's confusing that it implements the _Bool type which
comes from C99, but not the associated semantics.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages tcc depends on:
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
Versions of packages tcc recommends:
ii libc6-dev [libc-dev]2.3.2.ds1-22 GNU C Library: Development Librari
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320148: requests keep-alive though working on single (or the last) file
Always requesting keep-alive is not a bug because, when the Wget process exits, it automatically closes all TCP connections to the remote servers. Now if Wget hangs when talking to a web server that supports keep-alive connections, it's a different bug. In that case the question is not why does Wget request keep-alive on last file?, but why does Wget hang in the first place? Do you have a server with which you can repeat this? Any working example, either a running server, or a trivial HTTP::Daemon script, would be appreciated. For example, it works with Apache 2: $ wget -S www.apache.org --17:47:40-- http://www.apache.org/ = `index.html' Resolving www.apache.org... 192.87.106.226 Connecting to www.apache.org|192.87.106.226|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK ... Server: Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7a DAV/2 SVN/1.2.0-dev Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Length: 11,540 (11K) [text/html] 100%[=] 11,540 42.87K/s 17:47:41 (42.80 KB/s) - `index.html' saved [11540/11540] $ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304082: tcc: dumps core in Autoconf large file test
Package: tcc
Version: 0.9.22-2
Severity: normal
The following program makes tcc dump core:
#define _FILE_OFFSET_BITS 64
#include sys/types.h
#define LARGE_OFF_T (((off_t) 1 62) - 1 + ((off_t) 1 62))
int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
LARGE_OFF_T % 2147483647 == 1)
? 1 : -1];
int main (void)
{
return 0;
}
Autoconf-generated scripts use a variant of this check to determine the
flags needed for large file support. The idea is for the compiler to accept
the program iff off_t can represent 2**63. Although tcc apparently supports
long long, this program makes it dump core, leading configure to believe
that defining _FILE_OFFSET_BITS is useless!
Removing the first line works correctly -- in the sense that tcc will
complain about the invalid array size, as intended for 32-bit off_t.
The offending program can be reduced even further:
int array[(1LL 0) ? 1 : -1];
int main (void) { return 0; }
If either 1LL is changed to 1, or 0 is removed, the program compiles.
An even simpler program that causes the core dump is:
int array[1LL 0];
int main (void) { return 0; }
Again, either changing 1LL to 1 or omitting the shift causes core dump to go
away.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages tcc depends on:
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
-- no debconf information
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages tcc depends on:
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
