Please let us know which versions of these packages were used (and src.rpm etc if possible). This will help make sure we don't add more misery.

Thanks @smooge! Here are the SRPMs that were used for the internal builds:
https://mprahl.fedorapeople.org/python-requests-kerberos-0.10.0-8.el7eso.src.rpm
https://mprahl.fedorapeople.org/python-kerberos-1.2.5-5.el7eso.src.rpm

Hi @smooge, any luck with this?

I got sidelined before my PTO with some 'important projects'. I hope to look at this when I get back next week from my parents.

Thanks @smooge! If possible, it'd be nice to have this done by January 10th. No rush on this though.

Hi @smooge, do you think you'll be able to get to this soon?

@mprahl I'll take this one and assume that getting the current Fedora versions is fine for you, too, right?

Notes to myself:

• python-kerberos doesn't build
  • BuildError: package python-kerberos not in list for tag epel7-infra-candidate -- apparently an older version is in RHEL7, so this needs some kind of exception so we can build the newer one for epel7-infra
• python-requests-kerberos doesn't build either, from root.log in buildArch:

DEBUG util.py:600:  No matching package to install: 'python3-pytest'
DEBUG util.py:600:  No matching package to install: 'python3-mock'
DEBUG util.py:600:  No matching package to install: 'python2-kerberos'
DEBUG util.py:600:  No matching package to install: 'python3-kerberos'
DEBUG util.py:600:  No matching package to install: 'python3-cryptography'

python*-kerberos is clear, the other ones I have to find out if we should build them in EPEL proper or only for infra.

I found out that the pytest, mock and cryptography packages are available as python36-* packages for EPEL7. I'm not sure if the mock one is even needed because as unittest.mock, it's part of the Python 3 stdlib.

For this, we need to get Python3-only versions of python-kerberos and python-requests-kerberos into EPEL7. Here are the review tickets:

• python3-kerberos
• python3-requests-kerberos

@mprahl Just checking, with the above I'm assuming that it's okay for you to get Python 3 only versions of the packages. This makes maintenance easier, as they can be normal packages -- for Python 2 versions we'd have to work around the older versions present in plain RHEL.

@nphilipp sorry about the confusion. This is just to add newer Python 2 versions in the Fedora Infra epel7-infra-stg tags/repo and not in EPEL 7.

@mprahl, ahh the confusion was a little self-induced, if Python 3 packages would work for you, we could get by without special infra sauce here. Anyway, the packages are ready to be reviewed (and as I understand it, would be necessary so that you can make the jump to Python 3 with MBS eventually).

I'll look into building the SRPMs you linked above in the infra tag, or do you need/want newer versions (as some time has passed since you linked them)?

This needs python-kerberos cleared for the infra tag (as there is an older version in RHEL7), see issue #8843.

Hi @nphilipp, the MBS code does now work on Python 3 but I don't see a major benefit in having the deployed instance of MBS run on Python 3 on RHEL 7. If such an effort were to occur, I'd rather see it on RHEL 8 so that newer packages can be used.

Regardless, I no longer maintain MBS and so it is not my decision. @mikem and @breilly are the maintainers, so I'll defer this to them.

@nphilipp by the way, thank you for working on this ticket. :smile:

Hi @nphilipp, the MBS code does now work on Python 3 but I don't see a major benefit in having the deployed instance of MBS run on Python 3 on RHEL 7. If such an effort were to occur, I'd rather see it on RHEL 8 so that newer packages can be used.

Ah, then I'll kill off the reviews.

python-kerberos-1.2.5-5.el7.infra.1 and python-requests-kerberos-0.10.0-8.el7.infra are available in epel7-infra-stg, closing.