Robert Lemmen wrote:
> could you have a look at
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380278? what do you
> think?
I don't like putting it to stdout, as stdout can be used as the main
output of zsyncmake in some modes.
The message is not well phrased. What it is complaining about i
The latest version of prboom has incorporated a lot of fixes from
Prboom+. Both projects continue to be developed, and are sharing bug
fixes; but they have different objectives.
Prboom+ is not targetting linux, whereas PrBoom is, so - in my heavily
biased opinion - you should stick with prboom. At
Package: zsync
Severity: important
Version: 0.3.0-1
zsync-0.3.0 can get into a loop downloading the final block of a file
(and it fails to complete the update). This only occurs on uncompressed
streams - but it's serious enough to make 0.3.0 unsuitable for regular
use. 0.3.1 fixes this.
--
To
ve size that matters :-)
> 8192 is not a valid value, according to the referenced zsyncmake(1)
> manpage,
Good point about the man page; the documentation needs updating. I will
make explicit the block sizes considered sane for normal and for
compressed files for the next release.
--
Colin Phipp
if (newconn && header_result == 0) {
fprintf(stderr,"EOF from %s\n",rf->url);
> It would probably have worked sans the "Connection: close". I also wonder
> why it did try to download two block, because the partial file was created
> by partially d
critical path and the restriction
could be easily lifted. I may try that - but I doubt having more
precision than powers-of-two helps much.
--
Colin Phipps <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
e is unintentional and I will fix it, but I
bet the performance is still very sub-optimal. I may well blacklist
servers with certain zsync-unfriendly behaviour - I don't want it
connection-flooding bad web servers - if we find these are a problem.
I have fixed the proxy-string bug for the
7 matches
Mail list logo
