[Slackbuilds-users] Problems with libev source

Daniel Prosser dpross1100 at msn.com
Thu Dec 28 04:46:04 UTC 2017


Thank you for the information. I have forwarded this discussion on to
the libev developer along with your explanation of the problem. I will
leave it up to him to decide whether he wants to make any changes on his
end or just write it off as a wget problem (I would probably do that
latter, based on your explanation).

Dan

On Mon, Dec 25, 2017 at 07:12:51AM -0500, B Watson wrote:
> On 12/24/17, Daniel Prosser <dpross1100 at msn.com> wrote:
> > Okay, fair enough. Just to be clear though, it makes sense to you that
> > this problem does not occur for every tar archive downloaded with wget
> > (or the browser), hosted at any site? I've only encountered the problem
> > with files from the libev download page, so there seems to be something
> > different about those files that causes wget and the browser to compress
> > them when downloading, if that is indeed what's going on.
> 
> I can name 2 more SBo examples: audio/alsacap and games/gtklife. These two
> are different from yours (the saved file is un-gzipped, not double-gzipped
> like libev) but the cause and workaround are the same.
> 
> It's not the file itself, it's the server that's serving the file. It's
> sending a 'Content-encoding: gzip' header, which is redundant (the actual
> file is already gzipped). The old version of wget disregards this header,
> and the new version acts on it by default.
> 
> It also sends a Content-type header, as usual... if the Content-type is
> application/x-tar, wget and your browser "helpfully" decompress the file.
> If it's application/x-gzip, wget and your browser (sometimes, not sure
> what else is happening) will "helpfully" gzip the file, even though it's
> already gzipped.
> 
> You could argue that this means the server is misconfigured, and you
> might be right... but the fact remains, the old wget did one thing when
> talking to these servers, and the new one defaults to doing a different
> thing. Slackware 14.2 is supposed to be a stable release, meaning that
> patches aren't supposed to cause major changes in behaviour (which is
> exactly what we're seeing here). The wget devs acknowledge this is a
> bug, too:
> 
> http://lists.gnu.org/archive/html/bug-wget/2017-11/msg00059.html
> 
> If it were just me, I'd switch to curl and forget about it. But tools like
> sbopkg and sbotools use wget... also, so does slackpkg (some Slackware
> mirror might cause this same problem).
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
> 


More information about the SlackBuilds-users mailing list