Description of problem: I've just upgraded to F39 and now did fails with this error ... Version-Release number of selected component: did-0.20-3.fc39 Additional info: reporter: libreport-2.17.11 kernel: 6.5.6-300.fc39.x86_64 cmdline: /usr/bin/python3 -sP /usr/bin/did last week cgroup: 0::/user.slice/user-1000.slice/user/app.slice/app-org.kde.konsole-00f5f5499cfb40019942cc1d6c1b452b.scope uid: 1000 reason: base.py:102:__init__:AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you mean: 'read'? executable: /usr/bin/did type: Python3 package: did-0.20-3.fc39 runlevel: N 5 exception_type: AttributeError crash_function: __init__ interpreter: python3-3.12.0-1.fc39.x86_64 comment: I've just upgraded to F39 and now did fails with this error ... Truncated backtrace: base.py:102:__init__:AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you mean: 'read'? Traceback (most recent call last): File "/usr/bin/did", line 42, in <module> did.cli.main() File "/usr/lib/python3.12/site-packages/did/cli.py", line 192, in main custom_plugins = did.base.Config().plugins ^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.12/site-packages/did/base.py", line 102, in __init__ self.parser.readfp(codecs.open(path, "r", "utf8")) ^^^^^^^^^^^^^^^^^^ AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you mean: 'read'? Local variables in innermost frame: self: <did.base.Config object at 0x7f4a2c8290d0> config: None path: '/home/kvolny/.did/config'
Created attachment 1993077 [details] File: os_info
Created attachment 1993078 [details] File: environ
Created attachment 1993079 [details] File: mountinfo
Created attachment 1993080 [details] File: open_fds
Created attachment 1993081 [details] File: namespaces
Created attachment 1993082 [details] File: backtrace
Created attachment 1993083 [details] File: cpuinfo
Yeah, this has been fixed in https://github.com/psss/did/pull/313 and will be included in the next release. I'm planning a new release in the coming week(s). In the meantime you can use the fresh did version from the copr repo: https://copr.fedorainfracloud.org/coprs/psss/did/
Sadly the package in COPR does not provide an upgrade path, so it will get lost as soon as my updates are installed again. did-0.20-1.20231108152735322435.main.15.gb11caf1.fc39.noarch.rpm 2.2 MB/s | 166 kB 00:00 Dependencies resolved. ============================================================================================================================================================================= Package Architecture Version Repository Size ============================================================================================================================================================================= Installing dependencies: python3-feedparser noarch 6.0.10-6.fc39 fedora 164 k python3-sgmllib3k noarch 1.0.0-11.fc39 fedora 22 k Downgrading: did noarch 0.20-1.20231108152735322435.main.15.gb11caf1.fc39 @commandline 166 k Transaction Summary ============================================================================================================================================================================= Install 2 Packages Downgrade 1 Package Build taken from https://copr.fedorainfracloud.org/coprs/psss/did/build/6613018/
installation via pip fails too package did 0.20.1, installed using Python 3.12.0 - did .local/pipx/venvs/did/bin/did --version ✘ 130 Traceback (most recent call last): File "/home/todoleza/.local/pipx/venvs/did/bin/did", line 42, in <module> did.cli.main() File "/home/todoleza/.local/pipx/venvs/did/lib64/python3.12/site-packages/did/cli.py", line 192, in main custom_plugins = did.base.Config().plugins ^^^^^^^^^^^^^^^^^ File "/home/todoleza/.local/pipx/venvs/did/lib64/python3.12/site-packages/did/base.py", line 102, in __init__ self.parser.readfp(codecs.open(path, "r", "utf8")) ^^^^^^^^^^^^^^^^^^ AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you mean: 'read'? my system package version is same as in comment 0
thanks, the update fixes this https://bodhi.fedoraproject.org/updates/FEDORA-2023-7a6d530263 (hm, how to link it with this bug?)
FEDORA-2023-7a6d530263 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-7a6d530263
I've added the bug to the bodhi update.
(In reply to Tomas Dolezal from comment #9) > Sadly the package in COPR does not provide an upgrade path, so > it will get lost as soon as my updates are installed again. Hm, the copr packages should be newer than what was in the Fedora repo and the new release should be automatically picked up as it has bumped version. What exactly is not working for you?
Compared the latest release with the latest copr content and it seems as expected: > rpmdev-vercmp did-0.21-1.fc37.noarch 0.21-1.20231110224527064887.main.1.g71e2580.fc37 WARNING: hyphen in release1: 0.21-1.fc37.noarch rpmdev-vercmp <epoch1> <ver1> <release1> <epoch2> <ver2> <release2> rpmdev-vercmp <EVR1> <EVR2> rpmdev-vercmp # with no arguments, prompt Exit status is 0 if the EVR's are equal, 11 if EVR1 is newer, and 12 if EVR2 is newer. Other exit statuses indicate problems. did-0.21-1.fc37.noarch < 0.21-1.20231110224527064887.main.1.g71e2580.fc37
with testing repo it works as it should now :). in the mean time I resorted to the copr & versionlock exclude for the fedora's 0.20-3.fc39 version. (In reply to Petr Šplíchal from comment #14) > Hm, the copr packages should be newer than what was in the Fedora They weren't. See the last line of this comment. > repo and the new release should be automatically picked up as it > has bumped version. What exactly is not working for you? $ rpmdev-vercmp did-0.20-3.fc39 did-0.20-1.20231108152735322435.main.15.gb11caf1.fc39.noarch.rpm ✘ 11 WARNING: hyphen in release1: 0.20-3.fc39 WARNING: hyphen in release2: 0.20-1.20231108152735322435.main.15.gb11caf1.fc39.noarch.rpm rpmdev-vercmp <epoch1> <ver1> <release1> <epoch2> <ver2> <release2> rpmdev-vercmp <EVR1> <EVR2> rpmdev-vercmp # with no arguments, prompt Exit status is 0 if the EVR's are equal, 11 if EVR1 is newer, and 12 if EVR2 is newer. Other exit statuses indicate problems. did-0.20-3.fc39 > did-0.20-1.20231108152735322435.main.15.gb11caf1.fc39.noarch.rpm
Ah, I see, there were two automated release bumps on the dist-git side only. Will probably move to the same versioning/naming scheme as used by `tmt`. That should cover this case as well.
FEDORA-2023-7a6d530263 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.