Description of problem: did stop to work with previous settings ERROR Invalid plugin type 'bugzilla_redhat' in section 'bz'. Version-Release number of selected component (if applicable): did-0.14-2.fc29.noarch How reproducible: always Steps to Reproduce: 1.did Actual results: [psklenar@localhost ~] $ did ERROR Invalid plugin type 'bugzilla_redhat' in section 'bz'. [psklenar@localhost ~] $ DEBU=99 did Expected results: no error Additional info:
I'm afraid the problem is that this update[1] should have been never!!! pushed to F29[2] ... I guess now it is too late to unpush, AFAIK removing packages from stable is allowed only in case of serious security issues <useless_rant> to be honest, I'm not much excited about the development cycle of did it took many months until at least something was done, while during those long months, it was broken on F30 (could be workarounded by installing F29 packages) and on F31 (could not be workarounded) now when we see the update finally, it is thoughtlessly pushed into F29 less than a month before F29 EOL, breaking *the only* environment where 'did' worked so far - not sure about F30, but it still doesn't work on F31, see bug 1768371 </useless_rant> [1] https://bodhi.fedoraproject.org/updates/FEDORA-2019-ee8456ee9d [2] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases "Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience." "A rebase that required (or provided) a new Python ABI, for example, would almost certainly not be allowed." <= !!!!! "Package maintainers MUST: Avoid Major version updates, ABI breakage or API changes if at all possible."
Sorry to break your workflow. I was trying to sync the latest fixes to all supported Fedoras. Haven't realized that for F29 it is not such a good idea. Will be more careful in the future. If it makes sense I can revert the package to use Python 2 again. However, as far as I know, the internal plugins have been already updated so they should now work fine with the latest did package. Another option is to update to did-0.15 which contains fix for BZ#1768371. What do you think would be the best solution now?
Ok, as it probably does not make sense to push any updates to F29 now I propose to close this bug and redirect anyone who is still affected by the problem to pick the latest version from copr: https://copr.fedorainfracloud.org/coprs/psss/did/
(In reply to Petr Šplíchal from comment #3) > If it makes sense I can revert the package to use Python 2 again. > However, as far as I know, the internal plugins have been already > updated so they should now work fine with the latest did package. On Fedora 30, I hit the same problem. I have qa-tools-workstation-4.1-29.noarch which contains source and python 2 bytecode of the plugin, while latest did package did-0.15-1.fc30.noarch is python3 based. Am I using wrong qa-tools-workstation builds? ``` $ rpm -ql qa-tools-workstation | grep bugzilla_redhat /usr/share/qa-tools/python-modules/did/plugins/bugzilla_redhat.py /usr/share/qa-tools/python-modules/did/plugins/bugzilla_redhat.pyc /usr/share/qa-tools/python-modules/did/plugins/bugzilla_redhat.pyo $ file /usr/share/qa-tools/python-modules/did/plugins/bugzilla_redhat.pyc /usr/share/qa-tools/python-modules/did/plugins/bugzilla_redhat.pyc: python 2.6 byte-compiled ``` As a workaround, I downgraded did to did-0.12-3.fc30.noarch which is python 2 based.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.