Bug 1221459 - Review Request: hgsubversion - Mercurial extension for Subversion
Summary: Review Request: hgsubversion - Mercurial extension for Subversion
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Antonio T. (sagitter)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1216264
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-14 05:28 UTC by Dave Johansen
Modified: 2015-12-24 05:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-22 07:24:30 UTC
Type: ---
Embargoed:
anto.trande: fedora-review+


Attachments (Terms of Use)

Description Dave Johansen 2015-05-14 05:28:46 UTC
Spec URL: https://daveisfera.fedorapeople.org/hgsubversion_1.8.1/hgsubversion.spec
SRPM URL: https://daveisfera.fedorapeople.org/hgsubversion_1.8.1/hgsubversion-1.8.1-1.fc21.src.rpm
Description: hgsubversion is an extension for Mercurial that allows using Mercurial as a Subversion client.
Fedora Account System Username: daveisfera

Comment 1 Marcin Haba 2015-07-11 15:35:24 UTC
Hello,

During build process occurs following traceback:

 /usr/bin/python2 setup.py build
Traceback (most recent call last):
  File "setup.py", line 106, in <module>
    from hgsubversion.svnwrap import svn_swig_wrapper
  File "/builddir/build/BUILD/durin42-hgsubversion-dde1ade36a49/hgsubversion/__init__.py", line 49, in <module>
    import svncommands
  File "/builddir/build/BUILD/durin42-hgsubversion-dde1ade36a49/hgsubversion/svncommands.py", line 16, in <module>
    import svnwrap
  File "/builddir/build/BUILD/durin42-hgsubversion-dde1ade36a49/hgsubversion/svnwrap/__init__.py", line 28, in <module>
    from svn_swig_wrapper import *
  File "/builddir/build/BUILD/durin42-hgsubversion-dde1ade36a49/hgsubversion/svnwrap/svn_swig_wrapper.py", line 20, in <module>
    from svn import client
  File "/usr/lib64/python2.7/site-packages/svn/client.py", line 26, in <module>
    from libsvn.client import *
  File "/usr/lib64/python2.7/site-packages/libsvn/client.py", line 105, in <module>
    import libsvn.core
  File "/usr/lib64/python2.7/site-packages/libsvn/core.py", line 7285, in <module>
    svn_pool_create()
TypeError: svn_pool_create() takes exactly 2 arguments (0 given)

Comment 2 Marcin Haba 2015-07-11 16:06:20 UTC
I am not Fedora packages maintainer and even not Python developer, from these reasons my review notices are informal.

Because your package requires mercurial module for work (from global namespace of setup.py):


try:
    import mercurial
except ImportError:
    requires.append('mercurial')


in Spec you probably need to add:


Requires: mercurial


and define as Requires other Mercurial dependencies in Spec file if any.

Comment 3 Dave Johansen 2015-07-13 04:04:23 UTC
(In reply to Marcin Haba from comment #1)
> During build process occurs following traceback:
This is a problem with the SWIG bindings in subversion-python. See blocker bugzilla (#1216264).

(In reply to Marcin Haba from comment #2)
> Because your package requires mercurial module for work (from global
> namespace of setup.py):
> in Spec you probably need to add:
> Requires: mercurial
Good catch. Added along with a Requires for subversion-python.

> and define as Requires other Mercurial dependencies in Spec file if any.
Mercurial's only dependency is on python, but even if there were others I don't believe it would be required to add them here because a dependence on Mercurial implies a dependence on everything it depends on.

Comment 4 Marcin Haba 2015-07-13 04:52:22 UTC
Hello Dave,

About blocker #1216264, right. I missed this blocker in this ticket. Thanks for point me this SWIG binding bug in subversion-python.

Also thanks for explain Mercurial me dependecies.

I will back here to review, when subversion-python blocker be fixed.

Comment 5 Marcin Haba 2015-07-22 18:00:44 UTC
Hello,

@Dave:

I noticed that the SWIG bindings bug is already fixed, so I have started review feature request hgsubversion package.

The result RPM package builds successfully without errors or tracebacks. That is nice.

Also all unit tests cases finished well:

Ran 362 tests in 782.711s
OK

Installation went perfect either by:

dnf install ./hgsubversion-1.8.1-1.fc21.noarch.rpm

For know the hgsubversion usage I read begining of the documentation from here:

/home/gani/1221459-hgsubversion/rpms-unpacked/hgsubversion-1.8.1-1.fc21.noarch.rpm/usr/share/doc/hgsubversion/hgsubversion.html

that says:

"
 To create a new Mercurial clone, you can use a command such as the following:

 $ hg clone <repository URI> [destination]

   Or with a real example:

 $ hg clone http://python-nose.googlecode.com/svn nose-hg
"

For test I used a random selected SVN repository from fedorahosted:

$ hg clone http://svn.fedorahosted.org/svn/xmlto/ xmlto-hg
abort: 'http://svn.fedorahosted.org/svn/xmlto/' does not appear to be an hg repository:
---%<--- (text/html; charset=UTF-8)
<html><head><title>xmlto - Revision 82: /</title></head>
<body>
 <h2>xmlto - Revision 82: /</h2>
 <ul>
  <li><a href="AUTHORS">AUTHORS</a></li>
  <li><a href="COPYING">COPYING</a></li>
  <li><a href="ChangeLog">ChangeLog</a></li>
  <li><a href="FAQ">FAQ</a></li>
  <li><a href="INSTALL">INSTALL</a></li>
  <li><a href="Makefile.am">Makefile.am</a></li>
  <li><a href="NEWS">NEWS</a></li>
  <li><a href="README">README</a></li>
  <li><a href="THANKS">THANKS</a></li>
  <li><a href="config.h.in">config.h.in</a></li>
  <li><a href="configure.in">configure.in</a></li>
  <li><a href="doc/">doc/</a></li>
  <li><a href="format/">format/</a></li>
  <li><a href="xmlif/">xmlif/</a></li>
  <li><a href="xmlto.in">xmlto.in</a></li>
  <li><a href="xmlto.mak">xmlto.mak</a></li>
  <li><a href="xmlto.spec.in">xmlto.spec.in</a></li>
 </ul>
 <hr noshade><em>Powered by <a href="http://subversion.tigris.org/">Subversion</a> version 1.6.11 (r934486).</em>
</body></html>
---%<---
!

I also tried to use --layout single switcher, but without success:

$ hg clone --layout single http://svn.fedorahosted.org/svn/xmlto/ xmlto-hg
hg clone: option --layout not recognized
hg clone [OPTION]... SOURCE [DEST]

make a copy of an existing repository

options ([+] can be repeated):

 -U --noupdate          the clone will include an empty working copy (only a
                        repository)
 -u --updaterev REV     revision, tag or branch to check out
 -r --rev REV [+]       include the specified changeset
 -b --branch BRANCH [+] clone only the specified branch
    --pull              use pull protocol to copy metadata
    --uncompressed      use uncompressed transfer (fast over LAN)
 -e --ssh CMD           specify ssh command to use
    --remotecmd CMD     specify hg command to run on the remote side
    --insecure          do not verify server certificate (ignoring web.cacerts
                        config)

(use "hg clone -h" to show more help)


At the end I tried to checkout the same repository by subversion:

$ svn checkout http://svn.fedorahosted.org/svn/xmlto/
A    xmlto/xmlif
A    xmlto/xmlif/test
A    xmlto/xmlif/test/result-foo
A    xmlto/xmlif/test/result-bar
A    xmlto/xmlif/test/result-html
A    xmlto/xmlif/test/run-test
A    xmlto/xmlif/test/result-unrelated-condition
A    xmlto/xmlif/test/result-pdf
A    xmlto/xmlif/test/result-baz
A    xmlto/xmlif/test/result-no-condition
A    xmlto/xmlif/test/result-ps
A    xmlto/xmlif/test/test.xml
A    xmlto/xmlif/xmlif.c
A    xmlto/xmlif/xmlif.l
A    xmlto/AUTHORS
A    xmlto/configure.in
A    xmlto/ChangeLog
A    xmlto/THANKS
A    xmlto/format
A    xmlto/format/docbook
A    xmlto/format/docbook/txt
A    xmlto/format/docbook/xhtml-nochunks
A    xmlto/format/docbook/dvi
A    xmlto/format/docbook/ps
A    xmlto/format/docbook/html-nochunks
A    xmlto/format/docbook/javahelp
A    xmlto/format/docbook/awt
A    xmlto/format/docbook/epub
A    xmlto/format/docbook/xhtml
A    xmlto/format/docbook/svg
A    xmlto/format/docbook/fo
A    xmlto/format/docbook/html
A    xmlto/format/docbook/pdf
A    xmlto/format/docbook/man
A    xmlto/format/docbook/mif
A    xmlto/format/docbook/htmlhelp
A    xmlto/format/docbook/pcl
A    xmlto/format/fo
A    xmlto/format/fo/svg
A    xmlto/format/fo/txt
A    xmlto/format/fo/dvi
A    xmlto/format/fo/ps
A    xmlto/format/fo/pdf
A    xmlto/format/fo/awt
A    xmlto/format/fo/mif
A    xmlto/format/fo/pcl
A    xmlto/format/xhtml1
A    xmlto/format/xhtml1/svg
A    xmlto/format/xhtml1/txt
A    xmlto/format/xhtml1/dvi
A    xmlto/format/xhtml1/ps
A    xmlto/format/xhtml1/fo
A    xmlto/format/xhtml1/pdf
A    xmlto/format/xhtml1/awt
A    xmlto/format/xhtml1/mif
A    xmlto/format/xhtml1/pcl
A    xmlto/README
A    xmlto/config.h.in
A    xmlto/xmlto.spec.in
A    xmlto/doc
A    xmlto/doc/xmlto.xml
A    xmlto/doc/xmlif.xml
A    xmlto/INSTALL
A    xmlto/FAQ
A    xmlto/COPYING
A    xmlto/xmlto.in
A    xmlto/Makefile.am
A    xmlto/xmlto.mak
A    xmlto/NEWS

This test confirms that it is valid SVN repository.

THe hgsubversion is on place:

# ls -l /usr/lib/python2.7/site-packages/hgsubversion/ 
razem 736
-rw-r--r--. 1 root root  1993 05-07 10:46 compathacks.py
-rw-r--r--. 2 root root  2811 07-22 18:12 compathacks.pyc
-rw-r--r--. 2 root root  2811 07-22 18:12 compathacks.pyo
-rw-r--r--. 1 root root 25484 05-07 10:46 editor.py
-rw-r--r--. 2 root root 21925 07-22 18:12 editor.pyc
-rw-r--r--. 2 root root 21925 07-22 18:12 editor.pyo
...
...


Could you tell me if documentation is wrong or I missed something.

Thanks in advance for help.

When I be able to work with hgsubversion then I be continue review process for this feature requeste.

Thanks.

Comment 6 Marcin Haba 2015-07-22 18:31:02 UTC
One more info.

On system where I built hgsubversion result RPM I have the subversion libs that causes SWIG problem:

# dnf list installed subversion*
Last metadata expiration check performed 2:34:25 ago on Wed Jul 22 17:40:34 2015.
Zainstalowane pakiety
subversion.x86_64                 1.8.13-2.fc22          @System
subversion-libs.x86_64            1.8.13-2.fc22          @System
subversion-python.x86_64          1.8.13-2.fc22          @System


On system where I installed the result RPM I have the same subversion libs that causes SWIG problem:

# dnf list installed subversion*
Last metadata expiration check performed 1:06:36 ago on Wed Jul 22 19:02:04 2015.
Zainstalowane pakiety
subversion-libs.x86_64      1.8.13-2.fc22    @System
subversion-python.x86_64    1.8.13-2.fc22    @System

On system where I installed the result RPM also I experienced the same SWIG traceback:

>>> import hgsubversion
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/hgsubversion/__init__.py", line 49, in <module>
    import svncommands
  File "/usr/lib/python2.7/site-packages/hgsubversion/svncommands.py", line 16, in <module>
    import svnwrap
  File "/usr/lib/python2.7/site-packages/hgsubversion/svnwrap/__init__.py", line 28, in <module>
    from svn_swig_wrapper import *
  File "/usr/lib/python2.7/site-packages/hgsubversion/svnwrap/svn_swig_wrapper.py", line 20, in <module>
    from svn import client
  File "/usr/lib64/python2.7/site-packages/svn/client.py", line 26, in <module>
    from libsvn.client import *
  File "/usr/lib64/python2.7/site-packages/libsvn/client.py", line 105, in <module>
    import libsvn.core
  File "/usr/lib64/python2.7/site-packages/libsvn/core.py", line 7285, in <module>
    svn_pool_create()
TypeError: svn_pool_create() takes exactly 2 arguments (0 given)

So, my question is - why previously during first test the same version Spec and SRPM threw traceback during building, but now it does not throw this traceback during build process ?

At the end, I would mention that the subversion 1.8.13-7 is not available yet in repository:

# LANG=en dnf update subversion-libs subversion-python
Failed to set locale, defaulting to C
Last metadata expiration check performed 1:25:18 ago on Wed Jul 22 19:02:04 2015.
Dependencies resolved.
Nothing to do.
Complete!

Comment 7 Dave Johansen 2015-07-22 19:28:06 UTC
(In reply to Marcin Haba from comment #5)
> For test I used a random selected SVN repository from fedorahosted:
> 
> $ hg clone http://svn.fedorahosted.org/svn/xmlto/ xmlto-hg
> abort: 'http://svn.fedorahosted.org/svn/xmlto/' does not appear to be an hg
> repository:
> 
> Could you tell me if documentation is wrong or I missed something.

Did you enable hgsubversion ( https://mercurial.selenic.com/wiki/HgSubversion#Installation_and_Configuration )?

Comment 8 Marcin Haba 2015-07-22 20:03:31 UTC
Hello,

Thanks for quick reply.

No, I did not enable hgsubversion. Thanks for the link. I have never used Mercurial before ;-)

It might be good to mention about this step (adding rc file) in documentation, or provide this rc file in hgsubversion RPM package. What do you think about it?

So, I added rc file to /etc/mercurial/hgrc.d/ as below:

# cat /etc/mercurial/hgrc.d/hgsubversion.rc 
[extensions]
hgsubversion = /usr/lib/python2.7/site-packages/hgsubversion


And then I tried to use the same hg call as previously:
$ hg clone http://svn.fedorahosted.org/svn/xmlto/ xmlto-hg

As result I noticed segfault in dmesg:

[47575.983918] hg[25781]: segfault at 0 ip 00007f5b12b58abd sp 00007ffc310c4540 error 6 in libpython2.7.so.1.0[7f5b12ad8000+17c000]

I tried to use gdb as below:

gdb /usr/bin/python2.7
run /usr/bin/hg clone http://svn.fedorahosted.org/svn/xmlto/ xmlto-hg


Starting program: /usr/bin/python2.7 /usr/bin/hg clone http://svn.fedorahosted.org/svn/xmlto/ xmlto-hg
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7a93abd in dict_set_item_by_hash_or_entry () from /lib64/libpython2.7.so.1.0
...
...
(gdb) thread apply all bt
#0  0x00007ffff7a93abd in dict_set_item_by_hash_or_entry () from /lib64/libpython2.7.so.1.0
#1  0x00007ffff7a95ef4 in PyDict_SetItemString () from /lib64/libpython2.7.so.1.0
#2  0x00007fffeb6c2219 in SWIG_Python_SetConstant () from /usr/lib64/python2.7/site-packages/libsvn/_client.so
#3  0x00007fffeb6c2415 in svn_swig_py_get_commit_log_func_swigconstant () from /usr/lib64/python2.7/site-packages/libsvn/_client.so
#4  0x00007ffff7af58be in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#5  0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#6  0x00007ffff7af67d9 in PyEval_EvalCode () from /lib64/libpython2.7.so.1.0
#7  0x00007ffff7b064dc in PyImport_ExecCodeModuleEx () from /lib64/libpython2.7.so.1.0
#8  0x00007ffff7b06762 in load_source_module () from /lib64/libpython2.7.so.1.0
#9  0x00007ffff7b073f0 in import_submodule () from /lib64/libpython2.7.so.1.0
#10 0x00007ffff7b0767f in load_next () from /lib64/libpython2.7.so.1.0
#11 0x00007ffff7b08098 in PyImport_ImportModuleLevel () from /lib64/libpython2.7.so.1.0
#12 0x00007ffff7aede48 in builtin___import__ () from /lib64/libpython2.7.so.1.0
#13 0x00007ffff7af4f43 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#14 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#15 0x00007ffff7af55c6 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#16 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#17 0x00007ffff7a825ac in function_call () from /lib64/libpython2.7.so.1.0
#18 0x00007ffff7a5db03 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#19 0x00007ffff7aefac7 in PyEval_CallObjectWithKeywords () from /lib64/libpython2.7.so.1.0
#20 0x00007ffff7af261b in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#21 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#22 0x00007ffff7af67d9 in PyEval_EvalCode () from /lib64/libpython2.7.so.1.0
#23 0x00007ffff7b064dc in PyImport_ExecCodeModuleEx () from /lib64/libpython2.7.so.1.0
#24 0x00007ffff7b06762 in load_source_module () from /lib64/libpython2.7.so.1.0
#25 0x00007ffff7b073f0 in import_submodule () from /lib64/libpython2.7.so.1.0
#26 0x00007ffff7b07918 in ensure_fromlist () from /lib64/libpython2.7.so.1.0
#27 0x00007ffff7b0815a in PyImport_ImportModuleLevel () from /lib64/libpython2.7.so.1.0
#28 0x00007ffff7aede48 in builtin___import__ () from /lib64/libpython2.7.so.1.0
#29 0x00007ffff7af4f43 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#30 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#31 0x00007ffff7af55c6 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#32 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#33 0x00007ffff7a825ac in function_call () from /lib64/libpython2.7.so.1.0
#34 0x00007ffff7a5db03 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#35 0x00007ffff7aefac7 in PyEval_CallObjectWithKeywords () from /lib64/libpython2.7.so.1.0
#36 0x00007ffff7af261b in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#37 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#38 0x00007ffff7af67d9 in PyEval_EvalCode () from /lib64/libpython2.7.so.1.0
#39 0x00007ffff7b064dc in PyImport_ExecCodeModuleEx () from /lib64/libpython2.7.so.1.0
#40 0x00007ffff7b06762 in load_source_module () from /lib64/libpython2.7.so.1.0
#41 0x00007ffff7b073f0 in import_submodule () from /lib64/libpython2.7.so.1.0
#42 0x00007ffff7b0767f in load_next () from /lib64/libpython2.7.so.1.0
#43 0x00007ffff7b0805d in PyImport_ImportModuleLevel () from /lib64/libpython2.7.so.1.0
#44 0x00007ffff7aede48 in builtin___import__ () from /lib64/libpython2.7.so.1.0
#45 0x00007ffff7af4f43 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#46 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#47 0x00007ffff7af55c6 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#48 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#49 0x00007ffff7a825ac in function_call () from /lib64/libpython2.7.so.1.0
#50 0x00007ffff7a5db03 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#51 0x00007ffff7aefac7 in PyEval_CallObjectWithKeywords () from /lib64/libpython2.7.so.1.0
#52 0x00007ffff7af261b in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#53 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#54 0x00007ffff7af67d9 in PyEval_EvalCode () from /lib64/libpython2.7.so.1.0
#55 0x00007ffff7b064dc in PyImport_ExecCodeModuleEx () from /lib64/libpython2.7.so.1.0
#56 0x00007ffff7b06762 in load_source_module () from /lib64/libpython2.7.so.1.0
#57 0x00007ffff7b07c12 in load_package () from /lib64/libpython2.7.so.1.0
#58 0x00007ffff7b073f0 in import_submodule () from /lib64/libpython2.7.so.1.0
#59 0x00007ffff7b0767f in load_next () from /lib64/libpython2.7.so.1.0
#60 0x00007ffff7b0805d in PyImport_ImportModuleLevel () from /lib64/libpython2.7.so.1.0
#61 0x00007ffff7aede48 in builtin___import__ () from /lib64/libpython2.7.so.1.0
#62 0x00007ffff7af4f43 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#63 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#64 0x00007ffff7af55c6 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#65 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#66 0x00007ffff7af55c6 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#67 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#68 0x00007ffff7a825ac in function_call () from /lib64/libpython2.7.so.1.0
#69 0x00007ffff7a5db03 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#70 0x00007ffff7a6c95c in instancemethod_call () from /lib64/libpython2.7.so.1.0
#71 0x00007ffff7a5db03 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#72 0x00007ffff7ab3a63 in call_method () from /lib64/libpython2.7.so.1.0
#73 0x00007ffff7af2e44 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#74 0x00007ffff7af5666 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#75 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#76 0x00007ffff7af55c6 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#77 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#78 0x00007ffff7af55c6 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#79 0x00007ffff7af5666 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#80 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#81 0x00007ffff7a8268d in function_call () from /lib64/libpython2.7.so.1.0
#82 0x00007ffff7a5db03 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#83 0x00007ffff7af3560 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#84 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#85 0x00007ffff7af55c6 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#86 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#87 0x00007ffff7a8268d in function_call () from /lib64/libpython2.7.so.1.0
#88 0x00007ffff7a5db03 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#89 0x00007ffff7af3560 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#90 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#91 0x00007ffff7a8268d in function_call () from /lib64/libpython2.7.so.1.0
#92 0x00007ffff7a5db03 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#93 0x00007ffff7af3560 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#94 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#95 0x00007ffff7a8268d in function_call () from /lib64/libpython2.7.so.1.0
#96 0x00007ffff7a5db03 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#97 0x00007ffff7af3560 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#98 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#99 0x00007ffff7a8268d in function_call () from /lib64/libpython2.7.so.1.0
#100 0x00007ffff7a5db03 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#101 0x00007ffff7af3560 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#102 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#103 0x00007ffff7a8268d in function_call () from /lib64/libpython2.7.so.1.0
#104 0x00007ffff7a5db03 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#105 0x00007ffff7af3560 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#106 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#107 0x00007ffff7a8268d in function_call () from /lib64/libpython2.7.so.1.0
#108 0x00007ffff7a5db03 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#109 0x00007ffff7af3560 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#110 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#111 0x00007ffff7af55c6 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#112 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#113 0x00007ffff7af55c6 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#114 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#115 0x00007ffff7af55c6 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#116 0x00007ffff7af5666 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#117 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#118 0x00007ffff7af55c6 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#119 0x00007ffff7af5666 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#120 0x00007ffff7af5666 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#121 0x00007ffff7af5666 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#122 0x00007ffff7af66b4 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#123 0x00007ffff7af67d9 in PyEval_EvalCode () from /lib64/libpython2.7.so.1.0
#124 0x00007ffff7b0fbdf in run_mod () from /lib64/libpython2.7.so.1.0
#125 0x00007ffff7b10db2 in PyRun_FileExFlags () from /lib64/libpython2.7.so.1.0
#126 0x00007ffff7b11fc7 in PyRun_SimpleFileExFlags () from /lib64/libpython2.7.so.1.0
#127 0x00007ffff7b241e1 in Py_Main () from /lib64/libpython2.7.so.1.0
#128 0x00007ffff6d48700 in __libc_start_main () from /lib64/libc.so.6
#129 0x0000000000400729 in _start ()


Thanks in advance for help.

Comment 9 Marcin Haba 2015-07-22 20:07:38 UTC
Same plugin is loaded as shows below command:

# hg help hgsubversion
hgsubversion extension - integration with Subversion repositories

hgsubversion is an extension for Mercurial that allows it to act as a
Subversion client, offering fast, incremental and bidirectional
synchronisation.

At this point, hgsubversion is usable by users reasonably familiar with
Mercurial as a VCS. It's not recommended to dive into hgsubversion as an
introduction to Mercurial, since hgsubversion "bends the rules" a little and
violates some of the typical assumptions of early Mercurial users.

Before using hgsubversion, we *strongly* encourage running the automated
tests. See 'README' in the hgsubversion directory for details.

For more information and instructions, see "hg help subversion".

list of commands:

 svn           subcommands for Subversion integration

(use "hg help -v hgsubversion" to show built-in aliases and global options)

Comment 10 Marcin Haba 2015-07-22 20:38:39 UTC
Hello,

After download latest subversion 1.8.13-7 packages from here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=669141

and update:

# dnf update subversion-libs-1.8.13-7.fc22.x86_64.rpm subversion-1.8.13-7.fc22.x86_64.rpm subversion-python-1.8.13-7.fc22.x86_64.rpm

the hgsubversion started working:

$ hg clone http://svn.fedorahosted.org/svn/xmlto/ xmlto-hg
[r1] ovasik: xmlto release 0.0.21
[r2] ovasik: Initial commit to Fedorahosted XMLTO svn (version 0.0.21)
[r3] ovasik: fix broken stringparam option
[r4] ovasik: add --nonet and --noent option to xmllint validation check(fixes debian #516253)
...
...
...
[r81] ovasik: xmlif: fix segfault with malformed end attribute
[r82] ovasik: xmlif/xmlif.{c,l}: fix double free with invalid end attribute
pulled 82 revisions
updating to branch default
62 files updated, 0 files merged, 0 files removed, 0 files unresolved

It looks that the SWIG problem in subversion was the reason.

So, I have following suggestions:

1) add to Spec Requires and BuildRequires tags appropriate subversion dependecies (>= 1.8.13-7)
2) add a sample rc file /etc/mercurial/hgrc.d/ to enable hgsubversion extension

I a have question about tests cases from hgsubversion:

1) Why all tests executed by run.py finished successfully with installed subversion(-libs|-python) 1.8.13-2 that version caused segfault on clone action call?

Comment 11 Marcin Haba 2015-08-05 17:58:05 UTC
Hello Dave,

Do you have any news or comments in this ticket?

I am ready to perform informal review if you are interested, of course.

Thanks in advance for reply.

Comment 12 Dave Johansen 2015-08-15 16:48:05 UTC
(In reply to Marcin Haba from comment #10)
> 1) add to Spec Requires and BuildRequires tags appropriate subversion
> dependecies (>= 1.8.13-7)

I don't think that this is worth the trouble. Plus, it wouldn't be correct for all Fedora/EPEL releases.

> 2) add a sample rc file /etc/mercurial/hgrc.d/ to enable hgsubversion
> extension

I'll check with upstream on the recommended way to handle this. With most Mercurial extensions, they default to off and have to be enabled. I realize that this one is a bit different, so I just want to make sure that upstream is ok with the "enabled by default" approach.

> I a have question about tests cases from hgsubversion:
> 
> 1) Why all tests executed by run.py finished successfully with installed
> subversion(-libs|-python) 1.8.13-2 that version caused segfault on clone
> action call?

I'm not sure. Is this reproducible with the current version? If not, it's probably not worth spending any time on.

Comment 13 Marcin Haba 2015-08-16 15:08:18 UTC
Hello,

(In reply to Dave Johansen from comment #12)
> (In reply to Marcin Haba from comment #10)
> > 1) add to Spec Requires and BuildRequires tags appropriate subversion
> > dependecies (>= 1.8.13-7)
> 
> I don't think that this is worth the trouble. Plus, it wouldn't be correct
> for all Fedora/EPEL releases.

Yes, it is worth the "trouble". If somebody will try to use your Spec and SRPM to build hgsubversion with subversion < 1.8.13-7 then occur the same problem with swig - Traceback and segfaults. I think that it is obligatory to add dependecies that have chance to work with result RPM package.
 
> > 2) add a sample rc file /etc/mercurial/hgrc.d/ to enable hgsubversion
> > extension
> 
> I'll check with upstream on the recommended way to handle this. With most
> Mercurial extensions, they default to off and have to be enabled. I realize
> that this one is a bit different, so I just want to make sure that upstream
> is ok with the "enabled by default" approach.

OK. Thanks. I will be waiting on response in this subject.

> > I a have question about tests cases from hgsubversion:
> > 
> > 1) Why all tests executed by run.py finished successfully with installed
> > subversion(-libs|-python) 1.8.13-2 that version caused segfault on clone
> > action call?
> 
> I'm not sure. Is this reproducible with the current version? If not, it's
> probably not worth spending any time on.

No. Current version is OK with subversion >= 1.8.13-7. I double checked.

Comment 14 Dave Johansen 2015-08-17 20:22:37 UTC
(In reply to Marcin Haba from comment #13)
> Hello,
> 
> (In reply to Dave Johansen from comment #12)
> > (In reply to Marcin Haba from comment #10)
> > > 1) add to Spec Requires and BuildRequires tags appropriate subversion
> > > dependecies (>= 1.8.13-7)
> > 
> > I don't think that this is worth the trouble. Plus, it wouldn't be correct
> > for all Fedora/EPEL releases.
> 
> Yes, it is worth the "trouble". If somebody will try to use your Spec and
> SRPM to build hgsubversion with subversion < 1.8.13-7 then occur the same
> problem with swig - Traceback and segfaults. I think that it is obligatory
> to add dependecies that have chance to work with result RPM package.

This was technically an issue with subversion and not hgsubversion. It's been fixed in the repos and the fix doesn't require any change or rebuild on the part of hgsubversion. Basically, if hgsubversion had already been packaged, then this issue would have been introduced and then resolved without anything being required from hgsubversion, so having an explicit Requires or BuildRequires isn't completely true. Yes, to be "bug free" the requires is correct, but I don't believe that sort of information is intended to be captured in the packaging/.spec file and that's what Bugzilla and other issue trackers are for.

Plus, I'm planning on including hgsubversion in EPEL 7 which has subversion 1.7 and so putting a specific version on the Requires would be conditional, really complicated and honestly just doesn't make a lot of sense to me.

> > > 2) add a sample rc file /etc/mercurial/hgrc.d/ to enable hgsubversion
> > > extension
> > 
> > I'll check with upstream on the recommended way to handle this. With most
> > Mercurial extensions, they default to off and have to be enabled. I realize
> > that this one is a bit different, so I just want to make sure that upstream
> > is ok with the "enabled by default" approach.
> 
> OK. Thanks. I will be waiting on response in this subject.

hggit has to be enabled by the user after install (like basically all Mercurial extensions), and upstream agreed that this is the right model to continue using ( https://groups.google.com/forum/#!topic/hgsubversion/ek0rNLCPZ7E ).

> > > I a have question about tests cases from hgsubversion:
> > > 
> > > 1) Why all tests executed by run.py finished successfully with installed
> > > subversion(-libs|-python) 1.8.13-2 that version caused segfault on clone
> > > action call?
> > 
> > I'm not sure. Is this reproducible with the current version? If not, it's
> > probably not worth spending any time on.
> 
> No. Current version is OK with subversion >= 1.8.13-7. I double checked.

Ok, so I believe that there's nothing required of hgsubversion and the packaging of it.

Comment 15 Antonio T. (sagitter) 2015-08-31 19:41:21 UTC
Some tests fail.
Please, check them.

Comment 16 Dave Johansen 2015-09-06 17:35:47 UTC
This appears to be an issue related to subversion 1.9 ( https://groups.google.com/d/msg/hgsubversion/q47xvqDDmS0/mDIgsT8gFQAJ ). You can either wait until the issue is resolved or start the review with F22 since it is still using subversion 1.8.

Comment 17 Antonio T. (sagitter) 2015-09-06 17:57:28 UTC
It should work in rawhide to be approved.

Comment 18 Dave Johansen 2015-11-08 07:17:48 UTC
The issue has been resolved and all tests now pass on F23 and rawhide. The updated files can be found at:
Spec URL: https://daveisfera.fedorapeople.org/hgsubversion_1.8/hgsubversion.spec
SRPM URL: https://daveisfera.fedorapeople.org/hgsubversion_1.8/hgsubversion-1.8.3-1.fc22.src.rpm

Comment 19 Antonio T. (sagitter) 2015-11-08 16:50:52 UTC
- Why not a package for Python3 ?

- You can use 'nose' for an explicit output of tests.

- %{python_sitelib}/* --> %{python2_sitelib}/*

Comment 20 Dave Johansen 2015-11-08 21:32:08 UTC
(In reply to Antonio Trande from comment #19)
> - Why not a package for Python3 ?
Mercurial is Python 2 with no plans to move to Python 3 ( https://www.mercurial-scm.org/wiki/SupportedPythonVersions#Python_3.x_support ).

> - You can use 'nose' for an explicit output of tests.
I'm unfamiliar with 'nose'. Where would the change in the spec file be made and what would it be?

> - %{python_sitelib}/* --> %{python2_sitelib}/*
Fixed.

Comment 21 Antonio T. (sagitter) 2015-11-08 22:12:10 UTC
(In reply to Dave Johansen from comment #20)
> (In reply to Antonio Trande from comment #19)
> > - Why not a package for Python3 ?
> Mercurial is Python 2 with no plans to move to Python 3 (
> https://www.mercurial-scm.org/wiki/SupportedPythonVersions#Python_3.
> x_support ).
> 
> > - You can use 'nose' for an explicit output of tests.
> I'm unfamiliar with 'nose'. Where would the change in the spec file be made
> and what would it be?

hgsubversion's upstream maintainer uses python-nose for his tests:
https://pypi.python.org/pypi/nose/1.3.7

- Edit:

%check
nosetests -v


- Please, define what this package provides with:

%{?python_provide:%python_provide python2-%{name}}

Comment 22 Dave Johansen 2015-11-10 03:42:42 UTC
(In reply to Antonio Trande from comment #21)
> (In reply to Dave Johansen from comment #20)
> > (In reply to Antonio Trande from comment #19)
> > > - You can use 'nose' for an explicit output of tests.
> > I'm unfamiliar with 'nose'. Where would the change in the spec file be made
> > and what would it be?
> 
> hgsubversion's upstream maintainer uses python-nose for his tests:
> https://pypi.python.org/pypi/nose/1.3.7
> 
> - Edit:
> 
> %check
> nosetests -v
Fixed.

> - Please, define what this package provides with:
> 
> %{?python_provide:%python_provide python2-%{name}}

Since this is a mercurial extension, I'm not sure how useful it is as a standalone Python package, but I guess it doesn't hurt to add this and so I did.

Comment 23 Antonio T. (sagitter) 2015-11-10 10:56:12 UTC
Package approved.

Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed



===== MUST items =====

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "BSD (3 clause)", "Unknown or generated". 204 files have
     unknown license. Detailed output of licensecheck in
     /home/sagitter/1221459-hgsubversion/licensecheck.txt
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Package is not known to require an ExcludeArch tag.
[-]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 40960 bytes in 1 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %license.
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[x]: All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

Python:
[x]: Python eggs must not download any dependencies during the build
     process.
[-]: A package which is used by another package via an egg interface should
     provide egg info.
[ ]: Package meets the Packaging Guidelines::Python
[x]: Package contains BR: python2-devel or python3-devel
[x]: Binary eggs must be removed in %prep

===== SHOULD items =====

Generic:
[-]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Patches link to upstream bugs/comments/lists or are otherwise
     justified.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[x]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: hgsubversion-1.8.3-1.fc24.noarch.rpm
          hgsubversion-1.8.3-1.fc24.src.rpm
hgsubversion.noarch: E: incorrect-fsf-address /usr/share/licenses/hgsubversion/COPYING
2 packages and 0 specfiles checked; 1 errors, 0 warnings.




Rpmlint (installed packages)
----------------------------
hgsubversion.noarch: E: incorrect-fsf-address /usr/share/licenses/hgsubversion/COPYING
1 packages and 0 specfiles checked; 1 errors, 0 warnings.



Requires
--------
hgsubversion (rpmlib, GLIBC filtered):
    mercurial
    python(abi)
    subversion-python



Provides
--------
hgsubversion:
    hgsubversion
    python-hgsubversion
    python-hgsubversion(x86-32)



Source checksums
----------------
https://bitbucket.org/durin42/hgsubversion/get/1.8.3.tar.bz2#/durin42-hgsubversion-759cafce6bec.tar.bz2 :
  CHECKSUM(SHA256) this package     : 23942c3cf165242529c4e1323bbfa074de0d3b983cf960489e1caac73e7fcbaf
  CHECKSUM(SHA256) upstream package : 23942c3cf165242529c4e1323bbfa074de0d3b983cf960489e1caac73e7fcbaf


Generated by fedora-review 0.6.0 (3c5c9d7) last change: 2015-05-20
Command line :/usr/bin/fedora-review -m fedora-rawhide-i386 -b 1221459
Buildroot used: fedora-rawhide-i386
Active plugins: Python, Generic, Shell-api
Disabled plugins: Java, C/C++, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP, Ruby
Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6

Comment 24 Gwyn Ciesla 2015-11-11 14:23:00 UTC
Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/hgsubversion

Comment 25 Fedora Update System 2015-11-15 18:10:48 UTC
hgsubversion-1.8.3-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-817fc7a829

Comment 26 Fedora Update System 2015-11-15 18:10:54 UTC
hgsubversion-1.8.3-1.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-2d463375a9

Comment 27 Fedora Update System 2015-11-15 19:51:23 UTC
hgsubversion-1.8.3-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'yum --enablerepo=epel-testing update hgsubversion'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1d7e91d6ea

Comment 28 Fedora Update System 2015-11-16 04:50:45 UTC
hgsubversion-1.8.3-1.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update hgsubversion'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-2d463375a9

Comment 29 Fedora Update System 2015-11-16 05:53:05 UTC
hgsubversion-1.8.3-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update hgsubversion'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-817fc7a829

Comment 30 Fedora Update System 2015-12-22 07:24:27 UTC
hgsubversion-1.8.3-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

Comment 31 Fedora Update System 2015-12-22 22:07:39 UTC
hgsubversion-1.8.3-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 32 Fedora Update System 2015-12-24 05:07:20 UTC
hgsubversion-1.8.3-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.