FTBFS obviously due to recent rebuild that's not generated any python3-sip but python3-sip-devel only.
ttps://koji.fedoraproject.org/koji/buildinfo?buildID=1378142
https://src.fedoraproject.org/rpms/sip/c/f7175e4e20301e63d2bc8ac7bfa677c3a6eed4f6?branch=master

https://koji.fedoraproject.org/koji/buildinfo?buildID=1378142
https://src.fedoraproject.org/rpms/sip/c/f7175e4e20301e63d2bc8ac7bfa677c3a6eed4f6?branch=master

BTW python2-sip is missing, too.

Hi,

What's the rationale for sip 4.19.18-7 change "drop no_namespace variant for f31+"? What is supposed to provide python3-sip? Something like "python3-sip-api12"?

Victor

> What's the rationale for sip 4.19.18-7 change "drop no_namespace variant for f31+"? What is supposed to provide python3-sip? Something like "python3-sip-api12"?

Oh, I found the rationale: see bz #1748527. enki requirements should look like:
                                 
%{?_sip_api:Requires: python3-sip-api(%{_sip_api_major}) >= %{_sip_api}}

Some explanation could be found in bug #1748527.

Simplest fix would be to just remove
Requires: python3-sip

it's unclear to me why that's here or needed.  (Dependencies on python-qt5 should already pull in python3-pyqt5-sip, and you probably don't want more than one loaded at a time)

So I do see some explicit references to sip on enki source code in tests, though I question why:

tests/test_lib/test_future.py:import sip
tests/test_lib/test_future.py:            sip.delete(o)
tests/base.py:import sip
tests/base.py:    sip.delete(timer)
tests/base.py:    sip.delete(qe)

I would venture, possible fixes include:
* replacing 'sip' with 'PyQt5.sip'
or
* remmove references to sip altogether.

Rex, thanks for looking into this.

Maybe file the proposal to drop any dependency of sip as a patch or pull request to upstream?

That's a discussion to be had with your upstream, I'd prefer you do it, but I can as time allows.

Submitted
https://github.com/andreikop/enki/issues/464

(In reply to Rex Dieter from comment #11)
> Submitted
> https://github.com/andreikop/enki/issues/464

Upstream closed the issue without any patch or merge. How to proceed then for our package?

(In reply to Raphael Groner from comment #12)
> (In reply to Rex Dieter from comment #11)
> > Submitted
> > https://github.com/andreikop/enki/issues/464
> 
> Upstream closed the issue without any patch or merge. How to proceed then
> for our package?

Well, that's obviously a bummer or blocker to build properly any new package.

I'd say just disable the tests, as upstream said: "I do not support the tests now, because there are a lot of hard-to-track infrastructure problems and the tests consume much more time than save."

Tests are disabled for recent builds. But that's definitely not the recommended way.
Please keep this bug open in hope of an improved upstream reaction.

Wjat do you mean, disabling tests is not recommended?

That's literally what enki upstream tecommends...

Maybe those tests have a too complex design for our %check section meaning they've to run in a more common CI environment as we've with gating?

Be aware about the review guideline(s) for a package (mentioned also in fedora-review):
"SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example"
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_things_to_check_on_review

Probably my last comment on the topic...

sure, our guidelines *do* say you SHOULD run tests, but implicit there are some common-sense items too:
* does upstream recommend always running the tests downstream?
* are the tests reliable?
* are the tests useful?

In this case, I'd say most of answers to those questions is no.

I can mostly agree although the discussion here tends to get too generic and to run out of scope.

> %{?_sip_api:Requires: python3-sip-api(%{_sip_api_major}) >= %{_sip_api}}
> * replacing 'sip' with 'PyQt5.sip'
Would be a good starting point but we should try to not use any workarounds for the tests at downstream, should we?

Per comment #7 , you shouldn't need any explicit dependencies, and if you were to apply any downstream patch/workaround, it would be to patch code references to use 'PyQt5.sip' instead of just 'sip'

That said, I would argue against any downstream workarounds at this point.

Not reproducible (any more) in rawhide, see koschei's recent rebuilds.

No idea why koschei is stuck with new rebuilds for F31. Closing in behalf of low risk for this.