Re: svn server problem?
Hi, On Sat, Jul 15, 2017 at 09:06:08PM -0400, Richard L. Hamilton wrote: > With a browser, the URL with the @## suffix seems to redirect to > https://trac.macports.org/changeset/86927/contrib/MacPorts_Framework > while without the suffix, it at least comes up on a much plainer page. Yes. We added the redirect deliberately so that the git-svn-id headers created by our SVN->Git migration tooling would be clickable: https://github.com/macports/macports-base/commit/c610ee4ceaa500be41aa0d47c2c0f1f2c2d5e604 However, the SVN client does not send the @## part to the server when you run svn co on it. In fact, looking at the logs, I don't see any of the typical patterns an SVN client would send when attempting a checkout. Considering the checkout works for me with and without the @ suffix, do you happen to have any proxies or internet security utilities configured on your machine that might intercept your traffic? If you can rule that out, can you grab a packet capture for me, e.g. with Wireshark? > Also odd is that the version apparently identified by the suffix is > rather old, compared to the latest; I've got to wonder if the > Macports_Framework port has been updated in quite a while... That's not surprising, since the MacPorts_Framework code itself hasn't been touched in a while: https://github.com/macports/pallet/tree/master/MacPorts_Framework The Portfile should still be updated to fetch from GitHub instead of Subversion, though. -- Clemens
Re: svn server problem?
Rebooted my router; worked afterward. I have no proxies, and no particularly strange rules, certainly not for most sorts of client functionality. But, like most home routers, it NATs a single external address, and I have enough UPnP stuff (server processes, occasional BT client, etc), that I suppose an accumulation of rules that didn't time out could get ugly; Parallels Desktop is an example of something that doesn't clean up its rules (just keeps adding more periodically), so I already know I have to reboot the router once in a while to get rid of those. > On Jul 16, 2017, at 05:56, Clemens Lang wrote: > > Hi, > > On Sat, Jul 15, 2017 at 09:06:08PM -0400, Richard L. Hamilton wrote: >> With a browser, the URL with the @## suffix seems to redirect to >> https://trac.macports.org/changeset/86927/contrib/MacPorts_Framework >> while without the suffix, it at least comes up on a much plainer page. > > Yes. We added the redirect deliberately so that the git-svn-id headers > created by our SVN->Git migration tooling would be clickable: > > > https://github.com/macports/macports-base/commit/c610ee4ceaa500be41aa0d47c2c0f1f2c2d5e604 > > However, the SVN client does not send the @## part to the server > when you run svn co on it. > > In fact, looking at the logs, I don't see any of the typical patterns an > SVN client would send when attempting a checkout. Considering the > checkout works for me with and without the @ suffix, do you happen to > have any proxies or internet security utilities configured on your > machine that might intercept your traffic? > > If you can rule that out, can you grab a packet capture for me, e.g. > with Wireshark? > >> Also odd is that the version apparently identified by the suffix is >> rather old, compared to the latest; I've got to wonder if the >> Macports_Framework port has been updated in quite a while... > > That's not surprising, since the MacPorts_Framework code itself hasn't > been touched in a while: > > https://github.com/macports/pallet/tree/master/MacPorts_Framework > > The Portfile should still be updated to fetch from GitHub instead of > Subversion, though. > > -- > Clemens > signature.asc Description: Message signed with OpenPGP
Re: svn server problem?
> On Jul 16, 2017, at 06:55, Richard L. Hamilton wrote: > > Rebooted my router; worked afterward. > > I have no proxies, and no particularly strange rules, certainly not for most > sorts of client functionality. But, like most home routers, it NATs a single > external address, and I have enough UPnP stuff (server processes, occasional > BT client, etc), that I suppose an accumulation of rules that didn't time out > could get ugly; Parallels Desktop is an example of something that doesn't > clean up its rules (just keeps adding more periodically), so I already know I > have to reboot the router once in a while to get rid of those. That would be Parallels Access (remote desktop access to Mac that may be running Parallels VM's, and to the VM's on it) rather than Parallels Desktop. signature.asc Description: Message signed with OpenPGP
Re: expat 2.2.2 build fail on Snow Leopard
Well, that didn't work; also didn't work using configure.cppflags-append
instead. As far as I can tell, it didn't pick up the change to the environment
variable, at least I didn't see anything in the log indicating that it did; the
only reference to XML_POOR_ENTROPY was still in the error message.
> On Jul 16, 2017, at 00:29, Kenneth F. Cunningham
> wrote:
>
> Maybe something similar to this in the Portfile would work. Please give it a
> try. If it does, this might be your first pull request! -- Ken
>
>if {${os.platform} eq "darwin" && ${os.major} < 11} {
>configure.cflags-append-DXML_POOR_ENTROPY=1
>}
>
>
> On 2017-07-15, at 9:03 PM, Kenneth F. Cunningham wrote:
>
>>
>> On 2017-07-15, at 8:36 PM, Richard L. Hamilton wrote:
>>
>>> bypass this error by defining XML_POOR_ENTROPY
>>
>> looks like you have to do the above.
>>
>> Ken
>
signature.asc
Description: Message signed with OpenPGP
Re: expat 2.2.2 build fail on Snow Leopard
Too bad it wasn't a 'first try" fix. You have a few more options. Sometimes you
can dig around in the configure script or CMakeLists.txt file and find the
proper spot or item that way.
Or you can define XML_POOR_ENTROPY directly in the configure.env and/or
build.env variables in the Portfile. There is a description how to do that in
the "port phases" part of the macports website, IIRC.
It still appears to me that is what needs to get defined on the build line. How
it gets there remains to be discovered, it seems.
Best of luck!
Ken
On 2017-07-16, at 8:57 AM, Richard L. Hamilton wrote:
> Well, that didn't work; also didn't work using configure.cppflags-append
> instead. As far as I can tell, it didn't pick up the change to the
> environment variable, at least I didn't see anything in the log indicating
> that it did; the only reference to XML_POOR_ENTROPY was still in the error
> message.
>
>
>> On Jul 16, 2017, at 00:29, Kenneth F. Cunningham
>> wrote:
>>
>> Maybe something similar to this in the Portfile would work. Please give it a
>> try. If it does, this might be your first pull request! -- Ken
>>
>> if {${os.platform} eq "darwin" && ${os.major} < 11} {
>> configure.cflags-append-DXML_POOR_ENTROPY=1
>> }
>>
>>
>> On 2017-07-15, at 9:03 PM, Kenneth F. Cunningham wrote:
>>
>>>
>>> On 2017-07-15, at 8:36 PM, Richard L. Hamilton wrote:
>>>
bypass this error by defining XML_POOR_ENTROPY
>>>
>>> looks like you have to do the above.
>>>
>>> Ken
>>
>
Re: expat 2.2.2 build fail on Snow Leopard
On Jul 15, 2017, at 22:36, Richard L. Hamilton wrote: > :info:build libtool: compile: /opt/local/bin/clang-mp-3.9 -I./lib -I. -pipe > -Os -arch x86_64 -arch i386 -Wall -Wmissing-prototypes -Wstrict-prototypes > -fexceptions -fno-strict-aliasing -I/opt/local/include -DHAVE_EXPAT_CONFIG_H > -c lib/xmlparse.c -fno-common -DPIC -o lib/.libs/xmlparse.o > :info:build lib/xmlparse.c:56:3: error: You do not have support for any > sources of high quality entropy enabled. For end user security, that is > probably not what you want. Your options include: * Linux + > glibc >=2.25 (getrandom): HAVE_GETRANDOM, * Linux + glibc <2.25 > (syscall SYS_getrandom): HAVE_SYSCALL_GETRANDOM, * BSD / macOS > (arc4random_buf): HAVE_ARC4RANDOM_BUF, * libbsd (arc4random_buf): > HAVE_ARC4RANDOM_BUF + HAVE_LIBBSD, * Windows (RtlGenRandom): _WIN32. > If insist on not using any of these, bypass this error by defining > XML_POOR_ENTROPY; you have been warned. For CMake, one way to pass > the define is: cmake -DCMAKE_C_FLAGS="-pipe -O2 > -DHAVE_SYSCALL_GETRANDOM" . If you have reasons to patch this > detection code away or need changes to the build system, please open a > bug. Thank you! > :info:build # error \ > :info:build ^ > :info:build 1 error generated. > :info:build make: *** [lib/xmlparse.lo] Error 1 > > > Granted, Snow Leopard doesn't seem to have arc4random_buf() (I think it > first appeared in Lion). What workaround should there be for this?? > Build failures should be reported in the issue tracker so that we can track the fix properly. This issue has been reported here: https://trac.macports.org/ticket/54474 I'll deal with it at some point if nobody else gets to it first.
