Description of problem: copyq-3.12.0-4.fc33.x86_64 is built with old Qt version (5.14.2) so it can't be currently installed on Fedora 33. Please rebuild this package for Fedora 33. ``` $ sudo dnf install copyq Last metadata expiration check: 0:08:19 ago on Чт 15 окт 2020 20:32:42. Error: Problem: conflicting requests - nothing provides qt5-qtbase(x86-64) = 5.14.2 needed by copyq-3.12.0-4.fc33.x86_64 (try to add '--skip-broken' to skip uninstallable packages) ``` Version-Release number of selected component (if applicable): copyq-3.12.0-4.fc33.x86_64 Steps to Reproduce: Run `sudo dnf install copyq` in the console.
I can of course rebuild, but shouldn't this have occurred automatically? What happened? What other packages now are going to have this issue?
It should happen automatically provided pkgs depend on BuildRequires: qt5-qtbase-private-devel does it? (fedpkg clone is taking a long time, did sources get checked into git by accident?)
Looks like it does, maybe an overisight. I'll try to verify the versioned dep is really required, can you explain why it's needed? (hint, that justification should be included in the .spec, the current comment mentions private api, but I see not private api symbols used)
As threatened, https://src.fedoraproject.org/rpms/copyq/c/44e995be824d832484bcffbbc1805ecb10056572?branch=master I'd recommend merging that to f33, and do that build as an update instead, removes the hard-coded dep, makes things easier moving forward.
(In reply to Rex Dieter from comment #4) > As threatened, > > https://src.fedoraproject.org/rpms/copyq/c/ > 44e995be824d832484bcffbbc1805ecb10056572?branch=master > > I'd recommend merging that to f33, and do that build as an update instead, > removes the hard-coded dep, makes things easier moving forward. Earlier someone had split out qt5-qtbase and created qt5-qtbase-private-devel. You had put the referenced check and comment into yubioath-desktop. Since the split also affected copyq (because it won't compile now without private-devel) I inserted the same check and comment - following your lead. Was something moved to qt5-qtbase-private-devel by mistake? If it's included as a build dependency, isn't the method you specified the way you want to track it?
Rex, CopyQ 3.13.0 is out so I reversed out your changes (since private-devel is required) and added back in the referenced check for tracking as you used in yubioath-desktop. If this is incorrect or you have decided a better way to track, LMK, otherwise I'll assume you concur. Thanks!
Ok, adding the buildrequires is ok, but leave out the requires then
(In reply to Rex Dieter from comment #7) > Ok, adding the buildrequires is ok, but leave out the requires then OK, I'll take it out the next build. What about for yubioath-desktop? Remove it there also I assume? ## uses Qt5 private api's these help track that BuildRequires:▷⋅▷⋅⋅⋅qt5-qtbase-private-devel %{?_qt5:Requires: %{_qt5}%{?_isa} = %{_qt5_version}}
Sure, that should be safe to remove these days
Seeing this discussion, I've dropped the dependency on the private headers from source code, so building CopyQ 3.13.0 should not depend on the qt5-qtbase-private-devel.
(In reply to Lukas Holecek from comment #10) > Seeing this discussion, I've dropped the dependency on the private headers > from source code, so building CopyQ 3.13.0 should not depend on the > qt5-qtbase-private-devel. OK, I'll make the change next release.
*** Bug 1900601 has been marked as a duplicate of this bug. ***
FEDORA-2020-930a3e19b6 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-930a3e19b6
FEDORA-2020-930a3e19b6 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-930a3e19b6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-930a3e19b6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Hello, Please note that this comment was generated automatically. If you feel that this output has mistakes, please contact me via email (mhroncok). All subpackages of a package against which this bug was filled are now installable or removed from Fedora 34. Thanks for taking care of it!
FEDORA-2020-930a3e19b6 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.