Problem doing hg clone $tryton-env

Support Developer
#1

Hi,

As stated in How to develop:

hg clone https://hg.tryton.org/tryton-env
results in an error:

dot$ pip show mercurial
Name: mercurial
Version: 5.6

dot$ hg -v clone https://hg.tryton.org/tryton-env 
destination directory: tryton-env
applying clone bundle from https://downloads-cdn.tryton.org/bundles/tryton-env-bzip2-v1
adding changesets
adding manifests
transaction abort!                                                                                                                                             
rollback completed
(sent 2 HTTP requests and 434 bytes; received 1102 bytes in responses)
abort: error: None

I can sucessfully clone other repositories.

Am I doing something wrong or is this a problem?
Is the info outdated?
How to debug this?

Thanks.

#2

Works for me using mercurial 5.6

Maybe it is related to some network issues. Could you please retry?

#3

Also tried at my VPS, tried disabling the firewall, tried taking down ipv6 from the interface, tried running as root. Port 443 on inet4 hg.tryton.org seems open, however i am not sure about the inet6 hg.tryton.org.
Tried mercurial 5.0 and 5.6 under both python 2.7 and 3.8.

I tried mercurial both from pip and the one packaged by openbsd ports.

It is strange though that:

hg -v clone https://hg.tryton.org/modules/party

works.

@semarie I recall you were using OpenBSD. Does it work for you?

PS: This is not a new problem. I tried to clone tryton-env about two months ago with the same error. Suspects are my ipv4/ipv6 network and something with openbsd.

PS2: I am cloning into an empty directory

#4

I can confirm it is related to OpenBSD because it works on Linux on the same network.
Indeed I found that by default OpenBSD disable subrepos in /etc/mercurial/hgrc.d/openbsd-security.rc. You must enable it at least for https://hg.tryton.org/tryton-env.

#5

Yes, I am reproducing the error on OpenBSD when cloning (but it works when updating an already existent repository).

Yes, we disabled subrepos by default as it was security issue with it (see this commit on ports for details).

The problem doesn’t seems related to subrepos being disabled. I locally tested to reenable it globally, and I have the same behaviour.

#6

at syscall level, I have a ECONNRESET

 23137 python3.8 RET   read -1 errno 54 Connection reset by peer

@dotbit what is your OpenBSD version ?

#7

@ced: Changed the config file, same result.
Confirmed with:

dot# hg config|grep subrepo
subrepos.allowed=true

I also tested with subrepos.allowed=true, same results.
The error mercurial gives me if not very helpful.

@semarie: Latest syspatch-ed 6.8 on amd64.
I do not know how you checked the lasat syscall, accton?
Answer: hg --traceback

This is what I get:
ssl.SSLError: Connection reset by peer (_ssl.c:2627)

#8

could you report it on ports@openbsd.org ? it will be a better place to discuss it.

please include at least the following informations:

  • your openbsd version
  • the exact command-line you used (with --traceback) and the whole output it produced
  • you could mention the url of this thread, as @ced mentionned it works on linux from the same network
#9

I used ktrace(1), but it isn’t the better tool for python :smile: .

1 Like
#10

@semarie I will report it.

Thanks for the help!

#11

you should be able to workaround the problem by using --stream.

hg clone -v --config subrepos.allowed=true --stream https://hg.tryton.org/tryton-env
#12

That works. Now I can update as you mentioned.

#13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.