Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1574515

Summary: hg-git plugin seems not compatible with newest mercurial version
Product: [Fedora] Fedora Reporter: Jos de Kloe <josdekloe>
Component: hg-gitAssignee: Petr Stodulka <pstodulk>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 28CC: i, mads, patrick, pstodulk, sjoerd
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: hg-git-0.8.11-1.fc28 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-05-19 01:59:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jos de Kloe 2018-05-03 12:59:45 UTC
Description of problem:

any hg command gives me this error:
abort: cannot import name peerrepository!
unless I disable the hg-git plugin by removing the line
hggit=
from my $HOME/.hgrc file.

Version-Release number of selected component (if applicable):

hg-git-0.8.6-3.fc28.noarch
mercurial-4.4.2-4.fc28.x86_64

How reproducible:

always.
Also in a fresh new repository without any significant history.

Steps to Reproduce:
1. install mercurial and hg-git
2. add "hggit=" to the extensions section of the .hgrc file
3. run any hg command like "hg st" on a mercurial repository.

Actual results:

hg is not functional, and only gives the error
abort: cannot import name peerrepository!


Expected results:

a command like 'hg st' should show me the status of this repository but it doesn't.

Additional info:

downloading the latest version of the plugin with
hg clone https://bitbucket.org/durin42/hg-git
and installing it locally in my user account solves the problem:
cd hg-git/
python2 setup.py install --user

therefore most probably this package needs to be updated a.s.a.p. to a more recent version.

In addition, if you need help maintaining this package I would be happy to assist.

Comment 1 Petr Stodulka 2018-05-03 13:21:08 UTC
Hi Joe. I apologize for current state of the package as I am completely overloaded by my work and don't have time for maintainance last months. I will do rebase in minutes Could you do testing?

Additionaly, I would be happy if you join between maintainers of this package or even if you take it and I would stay just as co-maintainer, if you have time for that :-)

Comment 2 Jos de Kloe 2018-05-03 13:24:56 UTC
Hi, sure I can test for you as soon as you have an update.
Also I would be happy to co-maintain this package. My FAS user name is: jdekloe

Comment 3 Fedora Update System 2018-05-03 13:52:47 UTC
hg-git-0.8.11-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-7701b3fe16

Comment 4 Sjoerd Mullender 2018-05-03 17:34:15 UTC
As I also commented on bodhi, this isn't good enough.

With this version (0.8.11-1), hg works normally for non-git repositories where before it didn't.  So that is good.

However, when using a git repository, I still get an error which boils down to dulwich calling the run_command method provided by hggit (in hggit/_ssh.py) with more parameters than hggit accepts.  dulwich calls the run_command method with additional named parameters "password" and "key_filename".

It looks like the latest version of dulwich won't use those parameters if they aren't set, so that might help, but my feeling is that a better solution is to fix hggit.

Comment 5 Petr Stodulka 2018-05-04 06:23:49 UTC
I will see whether I will have time during saturday. Could you please post the reproducer here? Anyway, if you want, feel free to take the bug :-)

Comment 6 Sjoerd Mullender 2018-05-04 07:34:22 UTC
1. Find yourself a git repository that you can access with ssh.
2. Clone it, using mercurial and hg-git, on a system where this still works (e.g. Fedora 27), something like "hg clone git+ssh://...".
3. Transfer the repository to a Fedora 28 system.
4. Try any hg command that needs the remote repository (e.g. hg incoming).

This of course assumes you have the hggit extension enabled in your .hgrc file.

I get this traceback:

** unknown exception encountered, please report by visiting
** https://mercurial-scm.org/wiki/BugTracker
** Python 2.7.14 (default, Mar 14 2018, 16:45:33) [GCC 8.0.1 20180222 (Red Hat 8.0.1-0.16)]
** Mercurial Distributed SCM (version 4.4.2)
** Extensions loaded: hggit
Traceback (most recent call last):
  File "/usr/bin/hg", line 41, in <module>
    dispatch.run()
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 88, in run
    status = (dispatch(req) or 0) & 255
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 178, in dispatch
    ret = _runcatch(req)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 319, in _runcatch
    return _callcatch(ui, _runcatchfunc)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 327, in _callcatch
    return scmutil.callcatch(ui, func)
  File "/usr/lib64/python2.7/site-packages/mercurial/scmutil.py", line 154, in callcatch
    return func()
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 309, in _runcatchfunc
    return _dispatch(req)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 1033, in _dispatch
    cmdpats, cmdoptions)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 788, in runcommand
    ret = _runcommand(ui, options, cmd, d)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 1041, in _runcommand
    return cmdfunc()
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 1030, in <lambda>
    d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
  File "/usr/lib64/python2.7/site-packages/mercurial/util.py", line 1183, in check
    return func(*args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/mercurial/commands.py", line 3158, in incoming
    return hg.incoming(ui, repo, source, opts)
  File "/usr/lib64/python2.7/site-packages/mercurial/hg.py", line 912, in incoming
    return _incoming(display, subreporecurse, ui, repo, source, opts)
  File "/usr/lib64/python2.7/site-packages/mercurial/hg.py", line 875, in _incoming
    revs, opts["bundle"], opts["force"])
  File "/usr/lib64/python2.7/site-packages/mercurial/extensions.py", line 344, in closure
    return func(*(args + a), **kw)
  File "/usr/lib/python2.7/site-packages/hggit/__init__.py", line 316, in getremotechanges
    r, c, cleanup = repo.githandler.getremotechanges(other, revs)
  File "/usr/lib/python2.7/site-packages/hggit/git_handler.py", line 453, in getremotechanges
    result = self.fetch_pack(remote.path, revs)
  File "/usr/lib/python2.7/site-packages/hggit/git_handler.py", line 1230, in fetch_pack
    f.write, progress.progress)
  File "/usr/lib64/python2.7/site-packages/dulwich/client.py", line 737, in fetch_pack
    proto, can_read = self._connect(b'upload-pack', path)
  File "/usr/lib64/python2.7/site-packages/dulwich/client.py", line 1241, in _connect
    password=self.password, key_filename=self.key_filename)
TypeError: run_command() got an unexpected keyword argument 'password'

Comment 7 Jos de Kloe 2018-05-04 18:47:11 UTC
upstream has an issue on this as well:
https://bitbucket.org/durin42/hg-git/issues/236/issues-when-used-with-dulwich-019

Comment 8 Jos de Kloe 2018-05-04 19:40:29 UTC
The problem is that dulwich/client.py now uses keyword arguments named password and key_filename in the run_command method of the ssh_vendor.

The _Vendor class provided by hggit/_ssh.py still defines the run_command method without these keyword arguments.

On 2018-04-06 a workaround was added to dulwich:
Only pass key_filename and password into SSHVendor.run_command if they are set (for backwards compatibility) 

This fixes the problem for me. If I manually download and install the most recent versions of dulwich and hg-git and remove the rpm versions, then I can make again a connection between my local mercurial repository and a remove git repository.

So fasted solution is probably to have an update for dulwich, but I agree with Sjoerd that we should push hg-git to fix this a.s.a.p.

Comment 9 Fedora Update System 2018-05-06 10:06:15 UTC
hg-git-0.8.11-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-7701b3fe16

Comment 10 Sjoerd Mullender 2018-05-07 17:22:48 UTC
If I update hggit to 0.8.11-1.fc28 *and* I update python2-dulwich to 0.19.2-1.fc28 (currently in updates-testing), it works again!

With this combination, I can once again communicate with remote git repositories, and also with remove mercurial repositories.  The latter was only possible when the hggit extension was disabled, but now it is possible with the extension enabled.

Comment 11 Fedora Update System 2018-05-07 19:09:46 UTC
hg-git-0.8.11-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-7701b3fe16

Comment 12 Fedora Update System 2018-05-10 01:27:42 UTC
hg-git-0.8.11-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-7701b3fe16

Comment 13 Fedora Update System 2018-05-19 01:59:38 UTC
hg-git-0.8.11-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.