On Feb 2, 2018, at 8:34 AM, jungle Boogie wrote:
>
> Fifth solution: don't use TLS for this repo when you're using that platform.
If the repository is remote and you have login rights on it, I don’t consider
doing without encryption to be an option. My public repos
On 2 February 2018 at 07:08, Warren Young wrote:
> On Sep 16, 2017, at 12:57 PM, John Found wrote:
>>
>> On Sat, 16 Sep 2017 13:44:51 -0500
>> Andy Goth wrote:
>>
>>> Please type "openssl version" and let us know what it prints.
On Jan 24, 2018, at 3:15 PM, jungle Boogie wrote:
>
> $ fossil sync
> Sync with https://www.fossil-scm.org
> Round-trips: 1 Artifacts sent: 0 received: 79
> Sync done, sent: 1144 received: 3184 ip: 45.33.6.223
>
> I don't have write permissions to this repo. What
On 24 January 2018 at 13:45, Warren Young wrote:
> On Jan 24, 2018, at 1:47 PM, Warren Young wrote:
>>
>> On Sep 16, 2017, at 1:27 PM, Andy Goth wrote:
>>>
>>> Indeed, 1.1.0f is a version which includes the BIO_ADDR type, which is
On Jan 24, 2018, at 1:47 PM, Warren Young wrote:
>
> On Sep 16, 2017, at 1:27 PM, Andy Goth wrote:
>>
>> Indeed, 1.1.0f is a version which includes the BIO_ADDR type, which is a
>> union containing struct sockaddr_in6 among others. I don't think
On Sep 16, 2017, at 1:27 PM, Andy Goth wrote:
>
> Indeed, 1.1.0f is a version which includes the BIO_ADDR type, which is a
> union containing struct sockaddr_in6 among others. I don't think there's any
> question Fossil is trying to read an IPv6 address structure as if
On Wed, 1 Nov 2017 18:22:33 +0800
gumblex wrote:
> I still see the similar problem while cloning some fossil repos.
>
> For example, cloning https://www.fossil-scm.org/ and
> https://www.sqlite.org/cgi/src both shows 10.0.1.187. Cloning
>
I still see the similar problem while cloning some fossil repos.
For example, cloning https://www.fossil-scm.org/ and
https://www.sqlite.org/cgi/src both shows 10.0.1.187. Cloning
https://www.gaia-gis.it/fossil/libspatialite shows 2.0.1.187.
2017-09-16 03:16, John Found:
> I am not sure the
On Sat, 16 Sep 2017 14:27:37 -0500
Andy Goth wrote:
> Indeed, 1.1.0f is a version which includes the BIO_ADDR type, which is a
> union containing struct sockaddr_in6 among others. I don't think there's
> any question Fossil is trying to read an IPv6 address structure as
Indeed, 1.1.0f is a version which includes the BIO_ADDR type, which is a
union containing struct sockaddr_in6 among others. I don't think there's
any question Fossil is trying to read an IPv6 address structure as if it
were IPv4.
Try typing "ping asm32.info" and "ping6 asm32.info" (or whatever
On Sat, 16 Sep 2017 13:44:51 -0500
Andy Goth wrote:
> Please type "openssl version" and let us know what it prints.
>
OpenSSL 1.1.0f 25 May 2017
--
http://fresh.flatassembler.net
http://asm32.info
John Found
Please type "openssl version" and let us know what it prints.
I have version 1.0.2l, which has this in include/openssl/bio.h:
#define BIO_get_conn_ip(b) BIO_ptr_ctrl(b,BIO_C_GET_CONNECT,2)
Contrast with the latest OpenSSL which has:
typedef union bio_addr_st BIO_ADDR;
#define
On Sat, 16 Sep 2017 13:16:20 -0500
Andy Goth wrote:
> Do you have the same problem when you run a freshly compiled-from-scratch
> Fossil binary? We want to confirm you don't somehow have old object files
> linked in.
>
Yes. Checked twice. The fossil repository updated.
Do you have the same problem when you run a freshly compiled-from-scratch
Fossil binary? We want to confirm you don't somehow have old object files
linked in.
On Sat, Sep 16, 2017 at 1:04 PM, John Found wrote:
> On Sat, 16 Sep 2017 12:16:54 -0500
> Andy Goth
On Sat, 16 Sep 2017 12:16:54 -0500
Andy Goth wrote:
> The value of *ip will be 2. Instead try "p *ip@4" which will print four
> bytes, which will be 2, 0, 1, and 187.
(gdb) p *ip@4
$5 = "\002\000\001\273"
(gdb) continue
Sync done, sent: 1929 received: 0 ip: 2.0.1.187
The value of *ip will be 2. Instead try "p *ip@4" which will print four
bytes, which will be 2, 0, 1, and 187.
The issue appears to be somewhere within BIO_ptr_ctrl().
On Sat, Sep 16, 2017 at 12:10 PM, Andy Bradford
wrote:
> Thus said Andy Bradford on Sat, 16 Sep 2017
Thus said Andy Bradford on Sat, 16 Sep 2017 11:09:18 -0600:
> It might be useful here to also:
>
> print *p
Of course, I meant *ip
Andy
--
TAI64 timestamp: 400059bd5b14
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
Thus said John Found on Sat, 16 Sep 2017 20:03:16 +0300:
> Breakpoint 1, ssl_open (pUrlData=0x55a60c08 ) at
> ./src/http_ssl.c:394
> 394 g.zIpAddr = mprintf("%d.%d.%d.%d", ip[0], ip[1], ip[2], ip[3]);
> (gdb) p ip
It might be useful here to also:
print *p
Andy
--
TAI64
Here is what I got (hope I do it right):
$gdb --args fossil sync
Reading symbols from fossil...done.
(gdb) b http_ssl.c:394
Breakpoint 1 at 0x61187: file ./src/http_ssl.c, line 394.
(gdb) r
Starting program: /usr/bin/fossil sync
[Thread debugging using libthread_db enabled]
Using host
Thus said John Found on Fri, 15 Sep 2017 22:16:12 +0300:
> I recompiled fossil from the latest trunk version, but without change.
Did you run ``make clean'' before rebuilding?
Thanks,
Andy
--
TAI64 timestamp: 400059bd5902
___
fossil-users
I'm not seeing the original problem, by the way.
$ uname -a
Linux blind 4.9.45 #1 SMP Fri Aug 25 01:04:38 CDT 2017 x86_64 Intel(R)
Core(TM) i7-2620M CPU @ 2.70GHz GenuineIntel GNU/Linux
$ f clone https://asm32.info/fossil/repo/asmbb asmbb.fossil
Round-trips: 6 Artifacts sent: 0 received: 1586
Do you have gdb installed?
First, ensure you're using a recent version of Fossil, 2.2 or newer.
Run:
gdb --args fossil sync [any extra arguments go here]
b http_ssl.c:394
r
The sync will begin, then will be interrupted immediately before running
the requested line of code.
Type "p ip" to
Sadly, I do not know how to do such a thing as I am not a developer. The
concept is not foreign to me as I have a bit of experience with python, so I'll
give it a shot starting with Google. Pointers to get me on the right track
would be welcomed.
> On Sep 15, 2017, at 3:58 PM, Richard Hipp
On 9/15/17, Dewey Hylton wrote:
> just for completeness ... i verified that i am seeing the same address
> during a commit:
>
> Autosync: https://redacted
> Round-trips: 1 Artifacts sent: 0 received: 0
> Pull done, sent: 390 received: 994 ip: 2.0.1.187
> New_Version:
just for completeness ... i verified that i am seeing the same address
during a commit:
Autosync: https://redacted
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 390 received: 994 ip: 2.0.1.187
New_Version: 906246b7cd7e5fec91c69502981582bdbfc0a89e
Autosync: https://redacted
On 9/15/17, Richard Hipp wrote:
>
> Perhaps Apache is setting the REMOTE_ADDR environment variable. What
> does https://asm32.info/fossil/repo/asmbb/test_env show for the
> administrator? (You have that page turned off for anonymous, so I
> cannot see it.)
Nevermind - the
On 9/15/17, John Found wrote:
> I am not sure the problem is in fossil itself, but don't know from where to
> search it.
> Anyway, after sync command on one of my repositories, I get the following:
>
> Sync with https://asm32.info/fossil/repo/asmbb
> Round-trips: 1
i have noticed the same thing (i believe the same ip address even) and have
it on my to-look-at list for later. so i'm glad you brought this up. :)
- On Sep 15, 2017, at 3:16 PM, John Found johnfo...@asm32.info wrote:
> I am not sure the problem is in fossil itself, but don't know from where
I am not sure the problem is in fossil itself, but don't know from where to
search it.
Anyway, after sync command on one of my repositories, I get the following:
Sync with https://asm32.info/fossil/repo/asmbb
Round-trips: 1 Artifacts sent: 0 received: 0
Sync done, sent: 1930 received: 1817
29 matches
Mail list logo