Bug 1968789 - F35FailsToInstall: copr-backend
Summary: F35FailsToInstall: copr-backend
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: copr-backend
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Copr Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1969073
Blocks: PYTHON3.10 F35FailsToInstall
TreeView+ depends on / blocked
 
Reported: 2021-06-07 23:08 UTC by Miro Hrončok
Modified: 2021-09-22 06:57 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-06-17 14:12:13 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Miro Hrončok 2021-06-07 23:08:43 UTC
Hello,

Please note that this comment was generated automatically. If you feel that this output has mistakes, please contact me via email (mhroncok).

Your package (copr-backend) Fails To Install in Fedora 35:

can't install copr-backend:
  - nothing provides python(abi) = 3.9 needed by copr-backend-1.148-1.fc35.noarch
  
If you know about this problem and are planning on fixing it, please acknowledge so by setting the bug status to ASSIGNED. If you don't have time to maintain this package, consider orphaning it, so maintainers of dependent packages realize the problem.


If you don't react accordingly to the policy for FTBFS/FTI bugs (https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/), your package may be orphaned in 8+ weeks.

P.S. The data was generated solely from koji buildroot, so it might be newer than the latest compose or the content on mirrors.

P.P.S. If this bug has been reported in the middle of upgrading multiple dependent packages, please consider using side tags: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages

Thanks!

Comment 1 Miro Hrončok 2021-06-07 23:27:38 UTC
This bugzilla is likely a fallout from the Python 3.10 rebuild.

If your package (or some of the dependencies it has) failed to rebuild during the Python 3.10 rebuild, they now fail to install. To fix this, packages need to be rebuilt in Rawhide.

We will slowly triage the bugzillas, but we'd appreciate your help.

If you know this is blocked by an existing reported build failure or another package not yet rebuilt with Python 3.10, please mark it as such by using the "Depends On"/"Blocks" bugzilla fields. That will help us determine what failures to prioritize.

Thank you and sorry for the inconvenience. Let me know if you need any help.

Comment 2 Miro Hrončok 2021-06-15 00:29:42 UTC
Hello,

This is the first reminder (step 3 from https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs).

If you know about this problem and are planning on fixing it, please acknowledge so by setting the bug status to ASSIGNED. If you don't have time to maintain this package, consider orphaning it, so maintainers of dependent packages realize the problem.

Comment 3 Pavel Raiskup 2021-06-15 11:29:44 UTC
There's a rather long transitive list of build failures blocking us to rebuild the package (even the new release can't be built).

Comment 4 Miro Hrončok 2021-06-15 12:00:54 UTC
From my experience, you will always have this problem with packages depending on eventlet. I highly recommend trying to avoid that stack. Is the dependency on oslo-concurrency crucial for copr?

Comment 5 Pavel Raiskup 2021-06-15 13:11:02 UTC
> From my experience, you will always have this problem with packages depending on eventlet.

This is the first time for us since 
https://pagure.io/copr/copr/c/e4ea1dc881cd3729fc0438e1f6a3ea5c436dfbb5
which admittedly isn't long ...

>  Is the dependency on oslo-concurrency crucial for copr?

We use the nice high-level locking mechanism from oslo-concurrency.
Perhaps we could migrate out, though 'oslo_concurrency.lockutils.lock' was
the first reasonable and working implementation after several other
attempts.  So it's not going to be

Comment 6 Pavel Raiskup 2021-06-15 13:12:59 UTC
So it's not going to be a 1-minute work :-/

Comment 7 Miro Hrončok 2021-06-15 13:21:00 UTC
Thanks for the explanation.

The root of this dependency issue is bz1913291 in case you want to watch it.


Some history:

 - eventlet failed to rebuild with Python3.9: bz1794283
 - eventlet failed to rebuild with Python3.8: bz1716497
 - eventlet failed to rebuild with Python3.7: bz1594248

It gets fixed eventually.

Comment 8 Miro Hrončok 2021-06-15 13:28:00 UTC
I don't know much about file locking libraries, except that filelock it is used by some industry-standard Python tools, such as virtualenv and tox, as well as Red Hat's in-house projects such as fmf:

$ repoquery --repo=rawhide{,-source} --whatrequires python3-filelock
fmf-0:0.16.0-2.fc35.src
python-pytest-xdist-0:2.2.1-2.fc35.src
python-theano-0:1.1.2-1.fc35.src
python-tldextract-0:3.1.0-3.fc35.src
python-virtualenv-0:20.4.7-3.fc35.src
python3-fmf-0:0.16.0-2.fc35.noarch
python3-theano-0:1.1.2-1.fc35.noarch
python3-tldextract-0:3.1.0-3.fc35.noarch
python3-virtualenv-0:20.4.7-3.fc35.noarch
tox-0:3.23.0-3.fc35.noarch


Maybe it is worth checking out, maybe not, I'm out of here, this is off-topic :D Feel free to chat with me if you are interested.

Comment 9 Tomáš Hrnčiar 2021-06-17 14:12:13 UTC
(In reply to Miro Hrončok from comment #7)
> Thanks for the explanation.
> 
> The root of this dependency issue is bz1913291 in case you want to watch it.
> 
> 
> Some history:
> 
>  - eventlet failed to rebuild with Python3.9: bz1794283
>  - eventlet failed to rebuild with Python3.8: bz1716497
>  - eventlet failed to rebuild with Python3.7: bz1594248
> 
> It gets fixed eventually.

And it got fixed :)

Comment 10 Pavel Raiskup 2021-09-22 06:57:13 UTC
> I don't know much about file locking libraries, except that filelock it is used by some industry-standard Python tools, ...

Hmm, dead project per maintainer's claim:
https://github.com/benediktschmitt/py-filelock/issues/84 

But as there's no better alternative, I tend to propose py-filelock anyway for
copr backend, at least for this: https://pagure.io/copr/copr/issue/1423


Note You need to log in before you can comment on or make changes to this bug.