Unable to find file "QtWidgets/QtWidgetsmod.sip"

[Geremia]

Trying to build Calibre 5.16.1, but I get:

*
* Running build
*

Building 24 extensions
SIPing 3 files...
/usr/bin/python3 -c import os; os.chdir('/tmp/SBo/calibre-5.16.1/build/pyqt/pictureflow'); from sipbuild.tools.build import main; main(); --verbose --no-make --qmake /usr/bin/qmake-qt5
Querying qmake about your Qt installation...
/usr/bin/qmake-qt5 -query
These bindings will be built: pictureflow.
Generating the pictureflow bindings...
-c: Unable to find file "QtWidgets/QtWidgetsmod.sip"

I have
QMake version 3.1
Using Qt version 5.15.2 in /usr/lib64

[kovidgoyal]

You need pyqt5 if you are using one of those silly distros that split packages into dev and non dev versions then the -dev version of it

[akadaedalus]

I'm using a different silly distro (Gentoo) and it still fails with this error despite the existence of /usr/share/sip/PyQt5/QtWidgets/QtWidgetsmod.sip.

[snappahead]

Having this exact issue with Gentoo as well. QtWidgetsmod.sip is located in the same place:
/usr/share/sip/PyQt5/QtWidgets/QtWidgetsmod.sip

Where is the calibre build expecting it to be?

[kovidgoyal]

The calibre build doesnt expect it to be anywhere, that would be sip from the pyqt package. You will need to figure out just how gentoo has butchered their pyqt packaging and workaround it.

[snappahead]

Let me rephrase the question, so perhaps you can provide a more useful answer.
Where is the file located on your system when you successfully build calibre?

[kovidgoyal]

You seem to think the path is hardcoded somewhere, calibre is built on multiple systems. But sure, here you go:

/usr/share/sip/PyQt5/QtWidgets/QtWidgetsmod.sip

and

/usr/lib/python3.9/site-packages/PyQt5/bindings/QtWidgets/QtWidgetsmod.sip

[snappahead]

On the contrary, I'm trying to discover the differences there are, in an attempt to track down why the build isn't continuing.
Gentoo does not have the python3.*/site-packages/PyQt5/bindings directory created - an initial test of symlinking the missing *.sip files to that path does get the build to progress beyond the error reported. It then fails at:

Querying qmake about your Qt installation...
/usr/lib64/qt5/bin/qmake -query
These bindings will be built: pictureflow.
Generating the pictureflow bindings...
-c: Q_PID is undefined

Will keep investigating and see what I can find - that is - if it is of interest.

[kovidgoyal]

Doesn't gentoo have a calibre ebuild? Just read that to learn whatever it is you need to do to get it to build with gentoo's sip/PyQt package.

[akadaedalus]

Originally Posted by kovidgoyal

Doesn't gentoo have a calibre ebuild? Just read that to learn whatever it is you need to do to get it to build with gentoo's sip/PyQt package.

It's the ebuild that's failing. Since other people have reported this and there's no clear resolution, it made sense to seek advice from you or the person who reported the problem. No need to be prickly.

[kovidgoyal]

This is an issue with sip-build as produced by the gentoo package. Report it on the gentoo bug tracker.

[brainiacghost]

Originally Posted by kovidgoyal

This is an issue with sip-build as produced by the gentoo package. Report it on the gentoo bug tracker.

It has been reported on the gentoo bug tracker, this is people trying to work out a resolution, whilst calibre is a decent piece of software, there's no need to be rude to people trying to figure out a solution to a problem.

[kovidgoyal]

Originally Posted by brainiacghost

It has been reported on the gentoo bug tracker, this is people trying to work out a resolution, whilst calibre is a decent piece of software, there's no need to be rude to people trying to figure out a solution to a problem.

You think this is me being rude? You have a rude awakening ahead of you.

This is a bug in the distro package. One in a LONG line of bugs in distro packages. ALL of which end up wasting my time. It needs to be fixed in the distro. As I have posted on the calibre linux page for decades, in big, bold, red colored text

WARNING: calibre is a highly complex piece of software with lots of very finicky dependencies. If you install from source, you are on your own. Please do not open bug reports or expect any form of support. You have been warned.

I dont know why all these Linux distros think they are capable of modifying upstream software. They just cause endless breakage and waste people's time. A plague on all their houses.

As for this issue, despite the fact that I absolutely loathe squandering my time on distro created problems, I pointed out the problem days ago:

The calibre build doesnt expect it to be anywhere, that would be sip from the pyqt package. You will need to figure out just how gentoo has butchered their pyqt packaging and workaround it.

I suggest you read the ebuilds for sip/sip-build/sip-pyqt5/pyqt5 in gentoo, find out how they are modifying upstream PyQt5, undo that, and sip build will probably start working again.

[eschwartz]

*puts on distro packaging hat*

I would suggest that Gentoo take a look at how Arch Linux packages sip and PyQt5. I took a hasty look at the ebuilds and a massive red flag to me, is that Gentoo appears to be using sip4 and configure.py in order to build modern versions of PyQt5, which is IIRC entirely unsupported by PyQt5 and anyways involves using sip4 so uhhhhhhhhhhhh.

Can't possibly have a problem with sip-build as produced by the gentoo package, when your current technology stack doesn't use sip-build.

Calibre does use sip5, even in the ebuilds, so they're actually mixing sip4 and sip5 in the technology stack. This is technically not a modification of anything, and there is nothing to undo. It is, however, butchered.

I recommend the Gentoo developers seek guidance on the PyQt5 mailing list regarding the correct way to fundamentally package the technology stack, rather than deferring bugs to users and then again to arbitrary downstream projects that use PyQt5 as an ordinary consumer rather than somehow being the go-to experts in packaging PyQt5.

Failing that, they could defer bugs to users, and those users could seek guidance on the PyQt5 mailing list.

Failing that, either the Gentoo maintainers or the users could read the PyQt5 documentation (either the website documentation or the README file in the source tarball), which instructs users installing from source to use sip-install and does not mention configure.py at all.

Any or all of these attempts at seeking resolution are both:

• more productive
• less "rude" (???)

than interrogating the developer of one software project, about why a different software project isn't working.

After you've already been told by that developer, that the problem lies in the different software project.

Look, I could understand asking here in the first place during initial information gathering, but after having been told where the root of the problem is, there is simply no call to continue to reply with "Let me rephrase the question, so perhaps you can provide a more useful answer." or " it made sense to seek advice from you". The lot of you have sought advice, received it, and are roundly ignoring it.

It's not Kovid's job to know, figure out, or explain why the PyQt5 installation on Gentoo is broken. Honestly, it's not my job either, but at least it's adjacent to my job even if my distro actually works fine.

[eschwartz]

Note that Gentoo also upgraded their ebuilds to stop patching calibre with a revert of commit "Move to SIP v4" to go back to the sip v4 setup (which worked, because everything used sip v4). But they didn't add PyQt-builder as a build dependency, even though they added sip-5, and even though sip-5 uses PyQt-builder as a plugin.

I can only assume the person who reported that the change worked, had additional packages installed locally, and thus didn't notice the build dependency (which is, however, listed in calibre's list of sources...)

Sorry, my bad -- sip-5 is not added, sip 4 is still a pinned dependency, but if you happen to have sip-5 installed as an additional slot then the patch is no longer applied.

Does Gentoo not have mechanisms for building packages in isolated containers that don't have leaky implied build-deps due to other applications being coincidentally installed?