Sorry, but I currently don't have the time for that.

If you are willing to take care of the epel8 branch, I can make you a comaintainer. Otherwise, I'll have to close this as WONTFIX.

I am not much of a python packager, but have managed to do some spec file adjustments and a mock build of python-breath 4.11.1 (the latest that can reasonably run on EPEL8 due to other dependencies and was available for F29), so if building 4.11.1 for EPEL8 is acceptable, I am willing to be a co-maintainer.  My FAS userid is gtb.  Thanks.

Sorry for taking so long to respond to this: could you please try to get a a newer version of breathe to build?

(In reply to dan.cermak from comment #3)

> Sorry for taking so long to respond...

No problem, we all have other things to work on, and as you can see I am not exactly being quickly responsive either, so my apologies too.

> could you please try to get a a newer version of breathe to build?

As I mentioned, I did try, but found it was not (reasonably within the effort level I am comfortable making) possible, due to the dependency tree, and at least (maybe others) python3-sphinx being at version 1.7.6 in the PowerTools repo that made any python-breathe version greater than 4.11.1 unbuildable (python-breathe 4.12 (the next release) states the requirement to be python3-sphinx 1.8, and trying to build python-breath 4.12 on EPEL8 with python-sphinx 1.7.6 gets object attribute errors when running python-sphinx).

I am not entirely sure of the entire lineage of python3-sphinx in the CentOS PowerTools repo, but as I understand it, those packages come from the (licensed) EL8 CodeReady Linux Builder sources, and I don't expect one is likely to see python3-sphinx upgraded any time soon(*), and as I understand it, EPEL cannot replace/upgrade any EL derived versions, so one is basically between a rock and hard place regarding versions(**).

As EL8 is (approximately) based on F29, and F29 had python-breath 4.11.1, that is likely where one is going to be stuck for a bit.

If the 4.11.1 version is not acceptable, let us just drop the entire request and mark this bug WONTFIX.

If you care, here is a copr build for python-breath with the modified spec file (which essentially defangs the python2 variant of the build).

https://copr.fedorainfracloud.org/coprs/gtb/python-breathe/

Thanks.



(*) I have no way to know if EL 8.2 will bring updates to the CRB packages, but that would a future consideration.

(**) I am not clear if modules provides a way, even under the non-replace requirements, for EPEL to overlay EL versions, but I *am* sure I don't fully understand modules, and EPEL's capability with them, to have any idea how one might proceed.

(In reply to Gary Buhrmaster from comment #4)
> (In reply to dan.cermak from comment #3)
> 
> > Sorry for taking so long to respond...
> 
> No problem, we all have other things to work on, and as you can see I am not
> exactly being quickly responsive either, so my apologies too.
> 
> > could you please try to get a a newer version of breathe to build?
> 
> As I mentioned, I did try, but found it was not (reasonably within the
> effort level I am comfortable making) possible, due to the dependency tree,
> and at least (maybe others) python3-sphinx being at version 1.7.6 in the
> PowerTools repo that made any python-breathe version greater than 4.11.1
> unbuildable (python-breathe 4.12 (the next release) states the requirement
> to be python3-sphinx 1.8, and trying to build python-breath 4.12 on EPEL8
> with python-sphinx 1.7.6 gets object attribute errors when running
> python-sphinx).

I see, that is indeed a problem as breathe needs to fiddle quite a bit with sphinx and a higher version requirement is then a lot more work (especially if one is not familiar with sphinx' internals).

> 
> I am not entirely sure of the entire lineage of python3-sphinx in the CentOS
> PowerTools repo, but as I understand it, those packages come from the
> (licensed) EL8 CodeReady Linux Builder sources, and I don't expect one is
> likely to see python3-sphinx upgraded any time soon(*), and as I understand
> it, EPEL cannot replace/upgrade any EL derived versions, so one is basically
> between a rock and hard place regarding versions(**).
> 
> As EL8 is (approximately) based on F29, and F29 had python-breath 4.11.1,
> that is likely where one is going to be stuck for a bit.
> 
> If the 4.11.1 version is not acceptable, let us just drop the entire request
> and mark this bug WONTFIX.

Well, the question is more: are you willing to tackle the bug reports for a 2 year old breathe version ;-)

> 
> If you care, here is a copr build for python-breath with the modified spec
> file (which essentially defangs the python2 variant of the build).
> 
> https://copr.fedorainfracloud.org/coprs/gtb/python-breathe/
> 
> Thanks.
> 
> 
> 
> (*) I have no way to know if EL 8.2 will bring updates to the CRB packages,
> but that would a future consideration.
> 
> (**) I am not clear if modules provides a way, even under the non-replace
> requirements, for EPEL to overlay EL versions, but I *am* sure I don't fully
> understand modules, and EPEL's capability with them, to have any idea how
> one might proceed.

Well, modules would not really help here, as sphinx is a runtime dependency of breathe and not only a build time dependency. A build time dependency could be hidden in a module, but if a package from epel must not be overridden by a module, then modules will not be helpful here to cheat in a newer sphinx.

Long story short: if you are willing to maintain breathe 4.11 in epel and tackle any bugs that it receives, then I'll give you commit access to the repo and set you as the bugowner for the el8 branch. Deal?

As python-breathe cannot be updated in epel8, and I have insufficient expertice to backport any fixes in such a complex eco-system (breathe, sphinx, others?) I think that agreeing to take responsibility to actually address any bugs is wrong (all I could do is close WONTFIX as upstream is not going to backport anything either).

So, I see the only viable answer is close this bug WONTFIX.

Sorry to have wasted your time.

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

(In reply to Gary Buhrmaster from comment #6)
> As python-breathe cannot be updated in epel8, and I have insufficient
> expertice to backport any fixes in such a complex eco-system (breathe,
> sphinx, others?) I think that agreeing to take responsibility to actually
> address any bugs is wrong (all I could do is close WONTFIX as upstream is
> not going to backport anything either).

You could try to ask upstream what their stance on this is and/or on the epel-devel mailinglist if anyone else would be up to helping you out?

It's probably still going to be more work than in Fedora.

> 
> So, I see the only viable answer is close this bug WONTFIX.
> 
> Sorry to have wasted your time.

Please don't worry about it and maybe there is a solution as you are not the only one who wants breathe in EPEL 8.

FYI: BZ#1741567 (GDAL 3.1.0) requires python-breathe for EPEL8.
It is also an issue for the PDAL package on EPEL8 (BZ#1838686).

(In reply to markusN from comment #9)
> FYI: BZ#1741567 (GDAL 3.1.0) requires python-breathe for EPEL8.
> It is also an issue for the PDAL package on EPEL8 (BZ#1838686).

I will be more than happy to give a packager commit access to take care of a EPEL8 branch if they will also become the bugowner for EPEL8. Unfortunately I lack the time to maintain breathe in epel, so someone volunteering is required here.