This allows for token authentication in the newer versions of the API
that are being used on [1].

[1] - https://issues.redhat.com/

Note: I had to update my remote branch because it doesn't seem to update force pushes correctly in here (i.e. the diffs still show an outdated version) so I'm not sure if I'll be able to update this MR using my remote.

The whole section with runtime requires can be replaced just with%py_provides python3-%{distname} as noted in https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/#_provides

Maybe we can add %py3_check_import jira to check that the module is importable (note that this might need additional build requires).

I would replace this with

%{python3_sitelib}/%{modname}-*.egg-info/
%{python3_sitelib}/%{modname}/

to be consistent with the example at the end of https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/#_example_python_spec_file.

NIT: add the 3.2.0 source file to .gitignore please.

thanks for the PR @idoamara. You've re-added jirashell -- are you sure that ipython3 is available on EPEL8? (I.e. that the reason why it was removed does not apply)

Few months ago I split the package in two on Fedora because of ipython dependency; I'm not sure if the same reasoning would apply here.

Also thanks for the feedback @lzaoral. Some of it isn't strictly linked to the update per se, what do you think about doing it in a separate PR?

BTW, build of Isabella's version (ee982ac) succeeded in COPR: https://copr.fedorainfracloud.org/coprs/netvor/scratch/build/5635102/

but I don't have a functioning CentOS8/RHEL8 instance to test if it installs & works.

RHEL 8 machine with EPEL and CRB enabled and @netvor 's COPR:

[root@rhel8-vm ~]# dnf install ./python3-jira-3.2.0-1.el8.noarch.rpm
Last metadata expiration check: 0:07:45 ago on Tue 14 Mar 2023 07:17:16 AM EDT.
Error:
 Problem: conflicting requests
  - nothing provides python3.6dist(requests-oauthlib) >= 1.1.0 needed by python3-jira-3.2.0-1.el8.noarch
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

$ rpm -qRp python3-jira-3.2.0-1.el8.noarch.rpm 
warning: python3-jira-3.2.0-1.el8.noarch.rpm: Header V4 RSA/SHA256 Signature, key ID 050b598e: NOKEY
/usr/bin/python3.6
python(abi) = 3.6
python3-defusedxml
python3-ipython-console
python3-magic
python3-pbr
python3-requests
python3-requests-oauthlib
python3-requests-toolbelt
python3-six
python3.6dist(defusedxml)
python3.6dist(keyring)
python3.6dist(requests) >= 2.10.0
python3.6dist(requests-oauthlib) >= 1.1.0
python3.6dist(requests-toolbelt)
python3.6dist(typing-extensions) >= 3.7.4.2
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

I'm n ot sure which part of the SPEC file adds the 'python3.6*' deps.

COPR says (in copr settings) "Builds are done against RHEL + EPEL."

During the build, these packages are satisfied from modules, IIUC:

[..]
[..]
Finish: dnf update
Finish: chroot init
Start: build phase for python-jira-3.2.0-1.el8.src.rpm
Start: build setup for python-jira-3.2.0-1.el8.src.rpm
sh: /usr/bin/python3.6: No such file or directory
sh: /usr/bin/python3.6: No such file or directory
Building target platforms: x86_64
Building for target x86_64
Wrote: /builddir/build/SRPMS/python-jira-3.2.0-1.el8.src.rpm
No matches found for the following disable plugin patterns: local, spacewalk, versionlock
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use subscription-manager to register.

Copr repository                                  97 kB/s | 3.3 kB     00:00
Red Hat Enterprise Linux - BaseOS                27 kB/s | 4.1 kB     00:00
Red Hat Enterprise Linux - AppStream             31 kB/s | 4.5 kB     00:00
Red Hat Enterprise Linux - CodeReady Linux Buil  34 kB/s | 4.5 kB     00:00
Extra Packages for Enterprise Linux 8 - x86_64  662 kB/s |  23 kB     00:00
Dependencies resolved.
=============================================================================================================
 Package                              Arch    Version                                Repository          Size
=============================================================================================================
Installing:
 python3-pbr                          noarch  5.1.2-3.el8                            epel                88 k
 python3-pytest-cov                   noarch  1:2.6.0-1.el8                          epel                37 k
 python3-pytest-runner                noarch  4.0-4.el8                              epel                18 k
 python3-setuptools                   noarch  39.2.0-6.el8_7.1                       rhel-baseos        163 k
 python3-setuptools_scm_git_archive   noarch  1.1-4.el8                              epel                13 k
 python3-sphinx                       noarch  1:1.7.6-3.el8                          codeready-builder  1.7 M
 python36-devel                       x86_64  3.6.8-38.module+el8.5.0+12207+5c5719bc rhel-appstream      17 k
Installing dependencies:
 Lmod                                 x86_64  8.7.19-1.el8                           epel               263 k
 fontawesome-fonts                    noarch  4.7.0-4.el8                            rhel-appstream     203 k
[..]
[..]

I don't have time to go into this rabbit hole (and given state of EPEL8 I'm not sure it's worth it without assistence of OP) but if you want to
try it, here's what I did to get the COPR build working from package dir:

To create the SRPM, regardless of fedpkg/git:

rpmbuild -bs python-jira.spec --define "_topdir ." --define "_sourcedir ." --define "_srcrpmdir ." --define "dist .el8"

(Perhaps one should be able to do it via fedpkg but I'm not sure about the command; the obvious one required push.)

To build it in COPR, you can use COPR-CLI:

copr-cli create --chroot epel-8-x86_64 scratch
copr-cli build --chroot epel-8-x86_64 scratch python-jira-*.src.rpm
copr-cli download-build $BUILD_ID

The runtime dependencies are generated by the %python_provide python3-%{distname} macro from the configuration in setup.cfg. Its contents in 3.2.0 are: https://github.com/pycontribs/jira/blob/97ed6d78eab32b7c6c22efe622e7bc93ace010cb/setup.cfg#L59

It looks like downgrading the python3-requests-oauthlib dependency to 1.0.0 in setup.cfg works. The jirashell binary seems to work as well. However, the python3-ipython dependency is missing from the specfile.

Yeah, IIRC this was problem in the bug I mentioned.

Thing is, ipython is relatively heavy on deps itself, and in this lib it's only used for jirashell which is not a core feature -- that's why I decided to split off jirashell.

Doing the same here on epel8 smells of rabbit hole.

First, the packaging here is behind so I'm not sure it would work the way I did it on rawhide.

And even if we made it work, do we have guarrantee that 3.2.0 would actually work for @idoamara ? I have this doubt because I vaguely recall that, the reason I became co-maintainer was that I needed to do upgrade because RedHat's prod JIRA already had a sec. policy that required some newer version. We could end up having to ugrade even further (perhaps even getting ahead epel9) and (assuming it worked) I'm not sure if that isn't something that would be generally frowned upon in EPEL8.

WDYT?

My gut feeling is that if going to 3.5.0 is OK for EPEL8, then I would try and skip all the compromises and try to use something close to rawhide's SPEC.

If unsure, I'd go for the safe & lazy way: just downgrading oauthlib as you mention, and even leaving the ipython dep broken. (Merely adding it seems blunt: I suppose most people who use this lib just do import jira in some script and don't want to suddenly have 100's of megs of dependencies.)

then I would try and skip all the compromises and try to use something close to rawhide's SPEC

oh, and ofc. problem with this is that I don't have a test machine so this would rely on you guys :)

Sure, jirashell can be split into its own subpackage. However, we can't use a newer version because 3.2.0 is the last one that supports Python 3.6 which is the system default on RHEL 8. Also, @idoamara had to base her work on the f35 branch because the %py_project... macros used in newer branches are not available in EPEL 8. Otherwise, the package update would be trivial.

ahh, forgot how ancient RHEL8 is. Thanks, that pretty much leaves us with 3.2.0 and old packaging.

I'll try to make it work, with one objection: i'm hesitant to re-add ipython dependency. So I'll combine the original PR with suggestions from Lukáš, minus re-enabling the jirashell. (For access reasons it will be probably much faster for me to do it as new PR.)

If you really need jirashell on epel8 then i'd suggest opening new issue/PR. I might do that myself if I find splitting the package easy.

I found ubi8 container which should be close to rhel8.

I can build the version with downgraded oauthlib but I can't install it on the ubi8 image; apparently python3-requests-oauthlib is not available there at all.

Error: 
 Problem: cannot install the best candidate for the job
  - nothing provides python3-magic needed by python3-jira-3.2.0-1.el8.noarch
  - nothing provides python3-requests-oauthlib needed by python3-jira-3.2.0-1.el8.noarch
  - nothing provides python3.6dist(requests-oauthlib) >= 1.0.0 needed by python3-jira-3.2.0-1.el8.noarch

@lzaoral , could you please check it again and perhaps provide dnf install output? I wonder where did it get python3-oauthlib and python3-magic from..

My build is here:

https://copr.fedorainfracloud.org/coprs/netvor/km915-el8-python-jira/build/5651013/

I wonder where did it get python3-oauthlib and python3-magic from..

..the magic is irrelevant, turns out it was only used for the thing that was patched out, so I removed it. The question is still relevant for oauthlib, though.

Both python3-magic and python3-requests-oauthlib are in the BaseOS repository but they can be accessed from the ubi8 container only if you have a valid subscription. Otherwise, you should try a c8s container instead.

I don't have a valid subscription; where can i get this c8scontainer?

$ podman run --security-opt=seccomp=unconfined --rm -ti c8s
Trying to pull docker.io/library/c8s...
  denied: requested access to the resource is denied
Trying to pull registry.fedoraproject.org/c8s...
  manifest unknown: manifest unknown
Trying to pull registry.access.redhat.com/c8s...
  name unknown: Repo not found
Error: unable to pull c8s: 3 errors occurred:
    * Error initializing source docker://c8s:latest: Error reading manifest latest in docker.io/library/c8s: errors:
denied: requested access to the resource is denied
unauthorized: authentication required

    * Error initializing source docker://registry.fedoraproject.org/c8s:latest: Error reading manifest latest in registry.fedoraproject.org/c8s: manifest unknown: manifest unknown
    * Error initializing source docker://registry.access.redhat.com/c8s:latest: Error reading manifest latest in registry.access.redhat.com/c8s: name unknown: Repo not found


$

My apologies, I just meant it as an acronym for CentOS Stream 8. The official images (stream8 tag) are here: https://quay.io/repository/centos/centos?tab=tags

So as I've explained above, closing this and replacing with #7

Thanks a lot for the reviews, folks! I've been in touch with @lzaoral throughout the process as I don't have any experience with specfiles, and I'll address your suggestions soon :)

I completely missed @netvor's MR, sorry. Thanks a lot @netvor :)