Re: [Bug-wget] wget install issue

On Jun 24, 2016, at 9:42 PM, Yuling Liu wrote: > I am trying to install wget on my mac. I used homebrew to do so and I can > actually use wget --help Ok, so you've successfully installed the wget program. > but when I try to run my script it shows ImportError: > No module named wget. Do you

Re: [Bug-wget] wget IRI test failures on Mac OS X

On May 16, 2016, at 12:37 PM, Eli Zaretskii wrote: >> From: Ryan Schmidt <w...@ryandesign.com> >> Date: Thu, 12 May 2016 23:52:08 -0500 >> Cc: Micah Cowan <mi...@cowan.name> >> >> Hello, just wanted to gently remind you that this bug in the wget test

Re: [Bug-wget] pod2man --utf8 -> wget build failure

On May 24, 2016, at 5:55 AM, Tim Ruehsen wrote: > Hi Karl, > > thanks for pointing out those issue(s). > >> Perl... Exactly which version does not matter. > > It matters. AFAICS, Perl 5.8 introduced UTF-8 in 2002. > So perhaps your system is even older !? > (Just out of curiosity, what is it

Re: [Bug-wget] wget IRI test failures on Mac OS X

On Sep 24, 2009, at 5:24 PM, Ryan Schmidt wrote: > On Sep 24, 2009, at 12:57, Micah Cowan wrote: > >> It looks like the troubles your experiencing are due to the fact that >> the Wget tests assume that the filesystem can take any arbitrary set of >> bytes, and will store

Re: [Bug-wget] wget IRI test failures on Mac OS X

On May 18, 2016, at 3:21 AM, Tim Ruehsen wrote: > This HFS+ issue should be easy to fix, but without an environment to test it, > my motivation to spent my precious spare-time on that is pretty low. > > Ryan, how much trouble do you really have when using wget outside the test > suite ?

[Bug-wget] [bug #50223] wget 1.19 will not build on MacOS 10.12.3

Follow-up Comment #4, bug #50223 (project wget): Making the suggested change leads to: In file included from ftp.c:32: ../lib/unistd.h:139:3: error: "Please include config.h first." #error "Please include config.h first." ^ ../lib/unistd.h:141:1: error: unknown type name

[Bug-wget] [bug #50223] wget 1.19 will not build on MacOS 10.12.3

Follow-up Comment #5, bug #50223 (project wget): And adding #include "config.h" first before #include leads back to the originally reported error. ___ Reply to this item at:

AX_CODE_COVERAGE: command not found

Hi, I'm the maintainer of wget in MacPorts. Bruno already mentioned last week that during configure, wget 1.21.1 prints this: ./configure: line 51273: AX_CODE_COVERAGE: command not found I just wanted to add that this appears to be a result of not having had autoconf-archive installed when

implicit declaration of function 'utime' in trailing slashes test

Hi, I'm the maintainer of wget in MacPorts. In the version of clang included with Xcode 12 and later, implicit declaration of functions is an error. During configure, wget 1.12.1 prints this: checking whether utime handles trailing slashes on files... no config.log contains this:

Re: implicit declaration of function 'utime' in trailing slashes test

On Jan 22, 2021, at 16:47, Tim Rühsen wrote: > On 21.01.21 01:34, Ryan Schmidt wrote: >> Hi, I'm the maintainer of wget in MacPorts. >> In the version of clang included with Xcode 12 and later, implicit >> declaration of functions is an error. >> During co

Re: wget 1.21.1 fails to build on macOS (10.14, 10.15, 11.1)

On Jan 24, 2021, at 23:40, Carlo Cabrera wrote: > wget 1.21.1 fails to build on macOS 10.14, 10.15, and 11.1. The build > fails with a series of errors starting with > >In file included from regex.c:74: >In file included from ./regexec.c:1362: >./malloc/dynarray-skeleton.c:195:13:

Re: Wget2 cross-compile on iOS arm64

On Mar 22, 2021, at 17:56, Jeffrey Walton wrote: > It looks like this is an Autotools problem. Autotools should test if > ccp works as expected, and avoid cpp if it does not. Autotools should > not break the build. > > Perl works around Apple's cpp: >

Re: Wget2 cross-compile on iOS arm64

On Mar 23, 2021, at 04:01, Jeffrey Walton wrote: > On Tue, Mar 23, 2021 at 12:38 AM Ryan Schmidt wrote: >> >> On Mar 22, 2021, at 17:56, Jeffrey Walton wrote: >> >>> It looks like this is an Autotools problem. Autotools should test if >>> ccp work

Re: Wget2 cross-compile on iOS arm64

On Mar 21, 2021, at 05:41, Jeffrey Walton wrote: > I've been testing iOS cross-compiles. It looks like Wget2 is having > trouble with arm64: > > $ echo $CPPFLAGS > -DNDEBUG -isysroot > /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.2.sdk > > $

Re: Wget 1.21.1 on Apple M1

On Mar 6, 2021, at 21:37, Jeffrey Walton wrote: > Hi Everyone, > > I'm building Wget 1.21.1 on an Apple M1. Things go well for a while, and then: > > % make > /Library/Developer/CommandLineTools/usr/bin/make all-recursive > Making all in lib > /Library/Developer/CommandLineTools/usr/bin/make

Re: Wget 1.21.1 on Apple M1

On Mar 7, 2021, at 00:04, Jeffrey Walton wrote: > --without-included-regex is the default. (Or help is wrong. And I did > not add an option to enable it). Well if it were then you wouldn't see the problem, per the investigations that were done in January.

Re: Wget 1.21.1 on old PowerMac

On Mar 6, 2021, at 22:46, Jeffrey Walton wrote: > I'm building Wget 1.21.1 on an old PowerMac with OS X 10.5. Debian > still lacks a stable image for the G5's, so I keep using Apple's OS X. > > $ make > make all-recursive > Making all in lib > make all-am > ... > CC

Re: Wget 1.21.1 on Apple M1

On Mar 7, 2021, at 00:12, Jeffrey Walton wrote: > On Sun, Mar 7, 2021 at 1:06 AM Ryan Schmidt wrote: >> >> >> >> On Mar 7, 2021, at 00:04, Jeffrey Walton wrote: >> >>> --without-included-regex is the default. (Or help is wrong. And I did >&g