Installing borgbackup from epel was working as of last week.  Today, I can't seem to find python34-msgpack.  From another install, the package python34-msgpack-0.5.1-1.el7.x86_64 at one point existed, but today I can't find it anywhere.

I confirm, cannot find python34-msgpack-0.5.1-1.el7.x86_64.rpm anywhere, not even on mirrors. Is there any alternative? Thank you.

python34-msgpack was removed from EPEL 7 due to this commit https://src.fedoraproject.org/rpms/python-msgpack/c/fe28f04e292ce6a3f89c89c87a00415cc71e10bc?branch=epel7

  commit fe28f04e292ce6a3f89c89c87a00415cc71e10bc (HEAD -> epel7, origin/epel7)
  Author: Fabian Affolter <fabian>
  Date:   Mon Jun 18 16:56:19 2018 +0200

    Python2-only


That change was pushed via FEDORA-EPEL-2018-1daf05729e ( https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-1daf05729e ) and hence python34-msgpack is no more.

Unfortunately I was unable to find any change logs or bugs which explain why the Python 3-version was removed.

As this is really a problem in python-msgpack I took the liberty to reassign this bug.

@Fabian: Can you please provide insight about the reasoning in your commit? Were you aware that you broken borgbackup by doing so?

This is quote of the email by the maintainer of borgbackup:

  Is there an intention to package release 0.5.6 for epel7 too? Because
  its broken until 0.5.6 for borgbackup [2]. the current version in epel7
  is 0.5.1.

There is no mentioning that it requires Python 3 support and in EPEL is still Python 2 the default. Thus I removed Python 3 support to get 0.5.6 building.

This is very unfortunate. I found a (borgbackup) upstream issue which discusses msgpack compatibility [1]. Based on that it seems that msgpack 0.5.6 should work with borgbackup BUT msgpack stopped supporting Python 3.4 in October 2017 [2].

borgbackup only works with Python 3 so without a Python 3 msgpack version we have to pull borgbackup from EPEL (which I really want to avoid because I'm using borgbackup on *many* servers via EPEL).

The good news in all of that is that the upstram (msgpack) pull request does not specifically mention problems with Python 3.4, it seems to be just about getting rid of old versions.

I filed an (msgpack) upstream issue to learn more msgpack+Python 3.4 [3]. Fabian: Would you willing to carry some extra patches so we can reenable Python 3 support for EPEL 7? (I think even if we come up with some Python 3.4 patches AND msgpack upstream merges them we want to fix the EPEL issue immediately without waiting for an official msgpack release.)


[1] https://github.com/borgbackup/borg/issues/3753
[2] https://github.com/msgpack/msgpack-python/pull/249
[3] https://github.com/msgpack/msgpack-python/issues/306

*** Bug 1599893 has been marked as a duplicate of this bug. ***

INADA Naoki just reenabled testing for Python 3.4 [1]. Python 3.4 is not supported officially (no binary wheels, won't spend much effort fixing Python 3.4-specific bugs but will accept simple patches) but should be working for some time (maybe end of 2018).

Also I have to correct a previous statement of mine: "msgpack stopped supporting Python 3.4 in October 2017". As INADA Naoki pointed out msgpack stopped supporting 3.4 way before - just testing for 3.4 was disabled in October 2017.

I proceeded to enable Python 3 for EPEL 7. Basically this was about reverting fe28f04e [2] and fixing up some package names ('Cython', 'python2-pytest'). Also I had to remove "python-funcsigs" from the build requirements.

Good news is that the resulting package did build on EPEL 7 AND passed the test suite (I reenabled that as well). So I can not reproduce the initial build problems with Python 3 in EPEL.

@Fabian: How should we go ahead here? Should I send a pull request in pagure? Do you want to fix the package yourself? Any objections in general?


Also the "python-funcsigs" dependency is a bit surprising to me: EPEL 7 does not have a python34-funcsigs package so depending on it would be a problem. However msgpack passes all the tests even without funcsigs. Also I found no reference to that package upstream. I'm wondering if we actually need that package at all?


[1] https://github.com/msgpack/msgpack-python/commit/d1060de29309717355b78fe9092f7995897b4f0c
[2] https://src.fedoraproject.org/rpms/python-msgpack/c/fe28f04e292ce6a3f89c89c87a00415cc71e10bc?branch=epel7

For everyone who comes here from Google, as a workaround you can download the compiled binary from here: https://github.com/borgbackup/borg/releases rename to 'borg' and move somewhere to $PATH (i.e. /usr/local/bin).

Tested on CentOS 7 x64.

Perhaps this is better alternative:
http://springdale.math.ias.edu/data/puias/unsupported/7/x86_64//python34-msgpack-0.4.8-1.sdl7.x86_64.rpm until this is sorted...

I created a pull request for python-msgpack ( https://src.fedoraproject.org/rpms/python-msgpack/pull-request/4 ) so hopefully this problem can be fixed rather soon.

ping?

Even though the breakage happened a few weeks ago I'd really like to get this resolved ASAP. I opened some pull requests in pagure. If necessary I can become a co-maintainer to push the commits myself.
I'm "fschwarz" in FAS (already sponsored, helping with a few packages, ...).

+1

python-msgpack-0.5.6-3.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7f65484fe4

Nice; well done!

python-msgpack-0.5.6-3.el7 has been pushed to the Fedora EPEL 7 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-EPEL-2018-7f65484fe4

thank you. I will rebuild borgbackup asap.

https://bodhi.fedoraproject.org/updates/python-msgpack-0.5.6-3.el7#comment-823377
will the version pushed to epel or not?

Don't see your feedback.

You guys wanted a package for Python 3.4

Just an addition: The update will be pushed if we reach +3 otherwise after 14 days.

As of disscussion in [1]:
The Update indeed brings back python-msgpack to epel7, but the emitted warning still affects borgbackup.
The Testcases of Borgbackup requires a working Cython implementation. So the build of borgbackup fails with the current version of python-msgpack of FEDORA-EPEL-2018-7f65484fe4 [1].
Sure, there is a pure-python implementation, but other projects requiring also the Cython part.

For msgpack with python34 it seems to be a missing BuildRequires for python34-Cython. please accept my merge request [2].
I have tested a local build of the fixed version of python34-msgpack [2] with borgbackup and it seems to be working.

Please emit an update of the python34 package for a working Cython implementation.

If the update is in testing I encourage everyone to test it and add some karma if its working, to speed up the process to stable.

[1] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7f65484fe4 
[2] https://src.fedoraproject.org/rpms/python-msgpack/pull-request/5

python-msgpack-0.5.6-4.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-65bdd9ec8c

python-msgpack-0.5.6-4.el7 has been pushed to the Fedora EPEL 7 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-EPEL-2018-65bdd9ec8c

python-msgpack-0.5.6-4.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.