hplip-3.22.6-5.fc38.x86_64 ships an pcardext extension which cannot be loaded: >>> import pcardext Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: /usr/lib64/python3.11/site-packages/pcardext.so: undefined symbol: PyString_AsStringAndSize >>> Apparently, it hasn't been properly ported to Python.
I had to disable building the extension in hplip-3.22.10-2.fc38.
Hi Florian, thank you for reporting the issue and the patches! I don't use 'hp-unload' script, which uses the extension, but since this exception probably started to show up since we fully moved to Python3 as OS, IMHO there is no one else using it as well... So I would let your patch as it is, plus removed the dependent/relevant files. In case there is a demand to make it work I can use the similar implementation as: static inline int PyString_AsStringAndSize(PyObject* obj, char** buf, Py_ssize_t* psize) { if (PyUnicode_Check(obj)) { *buf = PyUnicode_AsUTF8AndSize(obj, psize); return *buf == NULL ? -1 : 0; } else if (PyBytes_Check(obj)) { return PyBytes_AsStringAndSize(obj, buf, psize); } PyErr_SetString(PyExc_TypeError, "Expecting str or bytes"); return -1; }
I've added some additional comments and reworked two patches: 1) _DBG() in orblite looks like typo for DBG() from common/utils.h 2) switched hpaio's compilation to -D_GNU_SOURCE mode to have declaration for strcasestr() - I saw you mentioned compatibility issues regarding the switch, would you mind telling what problems can show up due the switch? I did a similar change several years ago for hpipp compilation as well. The proposed update is now here https://src.fedoraproject.org/fork/zdohnal/rpms/hplip/c/e4cf0219ba15894f2f361cc8d3b4a56b32d2b467?branch=c99_cleanup .
(In reply to Zdenek Dohnal from comment #3) > I've added some additional comments and reworked two patches: > > 1) _DBG() in orblite looks like typo for DBG() from common/utils.h > 2) switched hpaio's compilation to -D_GNU_SOURCE mode to have declaration > for strcasestr() - I saw you mentioned compatibility issues regarding the > switch, would you mind telling what problems can show up due the switch? I > did a similar change several years ago for hpipp compilation as well. > > The proposed update is now here > https://src.fedoraproject.org/fork/zdohnal/rpms/hplip/c/ > e4cf0219ba15894f2f361cc8d3b4a56b32d2b467?branch=c99_cleanup . Using -D_GNU_SOURCE is fine if you can test things, I could not. Some functions change prototypes/behavior with -D_GNU_SOURCE, e.g. basename and strerror_r. I think bb_unload is still unused, so I'm not sure why it needs to be patched?
(In reply to Florian Weimer from comment #4) > Using -D_GNU_SOURCE is fine if you can test things, I could not. Some > functions change prototypes/behavior with -D_GNU_SOURCE, e.g. basename and > strerror_r. I've tested the basic scanning functionality and it went well, so it looks good to me for now. > > I think bb_unload is still unused, so I'm not sure why it needs to be > patched? I would like to keep the patches as small as possible, because as you can see there is a lot of them and upstream mostly does not communicate, just do releases which sometimes include some patches. So I would like to keep the function there (upstream might realize they can unload the binary, as they do with other plugins - it is not a critical though, since the backend is run as one-shot process and then OS cleans it up), so the future rebases might be easier.
FEDORA-2022-2a678c28c9 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-2a678c28c9
FEDORA-2022-6e7376d7da has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-6e7376d7da
FEDORA-2022-f90dc81076 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-f90dc81076
FEDORA-2022-6e7376d7da has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-6e7376d7da` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-6e7376d7da See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-2a678c28c9 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-2a678c28c9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-2a678c28c9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-f90dc81076 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-f90dc81076` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-f90dc81076 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-2a678c28c9 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-6e7376d7da has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-f90dc81076 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.