Bug 1946010 - F35FailsToInstall: electrum [NEEDINFO]
Summary: F35FailsToInstall: electrum
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: electrum
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Henrik Nordström
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F35FailsToInstall 1956632
TreeView+ depends on / blocked
 
Reported: 2021-04-03 14:35 UTC by Miro Hrončok
Modified: 2021-07-14 12:00 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-06-23 22:11:04 UTC
Type: ---
mhroncok: needinfo? (tredaelli)


Attachments (Terms of Use)

Description Miro Hrončok 2021-04-03 14:35:35 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 (electrum) Fails To Install in Fedora 35:

can't install electrum:
  - nothing provides (python3.9dist(aiorpcx) < 0.19 with python3.9dist(aiorpcx) >= 0.18.7) needed by electrum-4.1.0-1.fc35.noarch
  - nothing provides (python3.9dist(dnspython) < 2.1 with python3.9dist(dnspython) >= 2) needed by electrum-4.1.0-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-04-12 06:53:43 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 2 Miro Hrončok 2021-05-04 22:35:05 UTC
Hello,

This is the second reminder (step 4 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 Miro Hrončok 2021-06-09 12:04:10 UTC
This package has been orphaned.

You can pick it up at https://src.fedoraproject.org/rpms/electrum by clicking button "Take". If nobody picks it up, it will be retired and removed from a distribution.

Comment 4 Fedora Admin user for bugzilla script actions 2021-06-09 12:08:17 UTC
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

Comment 5 Henrik Nordström 2021-06-23 16:11:56 UTC
I do not fully understand why this FTI appened. The package needs to be reubilt to match Python version, and from what I can tell in both change history and koji history it was rebuilt for python 3.10, but still referenced the previous python-3.9 versions.

If the python dependent rebuild had been done correctly this FTI would not have happened.

Anyway it is now updated to a newer version and rebuilt, which should fix the issue. But how do I verify that it is solved? I do not have a F35 system to test on. @mhroncok

Comment 6 Miro Hrončok 2021-06-23 16:39:33 UTC
This problem was occurring before Python 3.10 rebuild, it was not related to or caused by the Python 3.10 rebuild.



Anyway, to verify, you can do:

$ mock -r fedora-rawhide-x86_64 --enablerepo=local install electrum
...
Error: 
 Problem: cannot install the best candidate for the job
  - nothing provides (python3.10dist(dnspython) < 2.1 with python3.10dist(dnspython) >= 2) needed by electrum-4.1.4-1.fc35.noarch
  - nothing provides python3.10dist(qdarkstyle) < 2.9 needed by electrum-4.1.4-1.fc35.noarch



So, currently, it is still not installable because there's dnspython 2.1.0 and qdarkstyle 3.0.2 in Fedora 35.

The current problem is also not related to the Python 3.10 rebuild.

Comment 7 Henrik Nordström 2021-06-23 17:45:07 UTC
Ok. I see.

Apparently they do not like the newer versions due to added dependencies, and this is picked up automatically in the fedora package requirements.

dnspython
https://github.com/spesmilo/electrum/commit/9d1f1e9732891527091a2a00bb9176f2b4ab90d8

qdarkstyle
https://github.com/spesmilo/electrum/commit/d1f860ccf39229121433bb125e5c12770c206270

Will check with upstream if there is any additional reasons behind the upper limit on the versions of these.

Comment 8 Henrik Nordström 2021-06-23 18:07:04 UTC
https://github.com/spesmilo/electrum/issues/7361

Comment 9 Henrik Nordström 2021-06-23 21:32:31 UTC
The dnspython max requirement is from what I can tell only due to the added buildsys requirements not wanted in upstream packaging process, which do not apply when packaging for Fedora. There is no added runtime dependencies, and no breaking API changes.

The qdarkstyle max requirement seems to be legacy only, and as a reminder to test and check if there is any new dependencies. There is no new depencencies, but not yet tested with version 3.0.

Current F35 build have relaxed both these requirements and will allow the package to be installed. But remains to verify if it works proper.

Comment 10 Henrik Nordström 2021-06-23 22:11:04 UTC
The build starts fine in the mock chroot and seems to work (GUI and network connection).


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