Unable to find file "QtWidgets/QtWidgetsmod.sip"

[eschwartz]

Aaand now tracked by https://bugs.gentoo.org/805965 so hopefully that gets resolved soon.

[brainiacghost]

Originally Posted by 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.

I had noticed that last night and worked on updating it - I've now updated the ebuild (not a gentoo maintainer / packager, just a user) and submitted a pull request.

Originally Posted by eschwartz

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.

I think calling it "interrogating" is a bit strong, it was asking some (in my view reasonable) questions. Whilst the answers were helpful (and I'm happy to admit that), the tone taken was a little antagonistic and that doesn't tend to lead to productive results, let's take:

Originally Posted by 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.

Sure, it gets the point across, but if it were rephrased in a less antagonistic manner, perhaps people wouldn't have continued to question the developer, something like:

"The calibre build doesnt expect it to be anywhere, that would be sip from the pyqt package. It's most likely a problem with the way that gentoo packages and builds PyQt, so you may want to start there, it's not something I can really help with"

It's a minor rephrasing, but comes across far less antagonistic and more positive in nature - I know that contributing to open source software can be a massive time sink and is often thankless, but people can easily be put off from helping because they get attacked for asking a question that might seem obvious to some people but isn't for others. The other thing to remember is that this is a public forum - it's not like this was an email sent directly to the developer, the initial question was asked on a relevent thread (I know I got here from searching for the error message).

Originally Posted by eschwartz

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.

I think that's a little harsh, there was a bit of a miscommunication, combined with perhaps not responding well to antagonistic tone. The other thing is that other packages that depend on PyQt didn't seem to have build failures, so it made sense to initially seek out the issue here. It does take slightly longer than a day sometimes to try and figure out the issue with an unfamiliar build system particularly when no one on this thread is actually one of the gentoo devs / maintainers. As it happens I'd already figured out the issue and was working on a solution when you replied.

Originally Posted by eschwartz

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.

I agree, it isn't his job (or yours), or anyone's really, and we are all entitled to respond to issues in the way we want to, but perhaps stepping back and thinking about how things could be percieved prior to hitting send could go a long way towards encouraging people to find their own solutions and contributing them back to the community.

I do appreciate that there is relevent information in both yours and Kovid's posts, and I don't want this to come across as me being ungrateful - I know that it's no one's job except the relevent package maintainer to sort out build issues like this, but one of the first things I do when debugging an issue (after trying the obvious) is ask to see if anyone else has had a similar issues, and the calibre development forum seems an appropriate place to do this given google searches were coming up with zilch.

For reference, the PyQt5 ebuild used a deprecated build system (I'm unsure when it changed from configure.py to sip-build, as old versions of the PyQt5 documentation mentions configure.py), that required updating. Additionally, not all of the flags passed to the old build system directly translated across so there needed to be a little bit of tinkering with configuration flags to ensure that PyQt5 would build properly. Once that's updated in the main portage tree, a calibre ebuild for the latest version (5.24.0) will build OK and the zeroconf errors that were also happening due to a zeroconf update have been fixed thanks to Kovid's dependencies being updated.

[eschwartz]

Originally Posted by brainiacghost

Sure, it gets the point across, but if it were rephrased in a less antagonistic manner, perhaps people wouldn't have continued to question the developer, something like:

"The calibre build doesnt expect it to be anywhere, that would be sip from the pyqt package. It's most likely a problem with the way that gentoo packages and builds PyQt, so you may want to start there, it's not something I can really help with"

It's a minor rephrasing, but comes across far less antagonistic and more positive in nature - I know that contributing to open source software can be a massive time sink and is often thankless, but people can easily be put off from helping because they get attacked for asking a question that might seem obvious to some people but isn't for others. The other thing to remember is that this is a public forum - it's not like this was an email sent directly to the developer, the initial question was asked on a relevent thread (I know I got here from searching for the error message).

Perhaps.

For what it's worth, linux distros have historically messed up calibre in some fairly weird ways, to the point that it was basically impossible to have a distro version that actually worked sanely.

This bothered me immensely, since I am a packager for a distro, so I've contributed immensely to calibre development in order to add distro-specific build options, tighten the source build integrations, and take advantage of the python3 migration (which I also helped to massively drive) to sort out (or encourage Kovid to sort out) the status of a number of forked and modified vendor dependencies so that they can use the upstream versions, since patching them out did not in fact actually work.

Which ironically caused bugs such as https://bugs.gentoo.org/705088#c3 (9 months of calibre on Gentoo having a broken recipes subsystem and more). I had mentioned this on the forums a couple months prior to that bug report, but at the time I guess it never got submitted as a bug.

Kovid is, well, "cautious" about distros. But my packages have never caused him issues (quite the opposite), which I guess earns me a few points. Also I've made it a lot harder for distros to mess up calibre, e.g. the xdg-* hacks every distro had are now obsolete because my personal hack which obviously I believe is the best, is now included in calibre's build system, and it's no longer required to patch calibre to use the system mathjax or liberation-fonts because there are now "python3 setup.py build" options to do that in a supported manner.

Speaking of making it harder to mess up calibre packaging, maybe you would like to improve the Gentoo ebuild to run a test phase with the calibre testsuite? It should be quite trivial to run, with the caveat that it needs to run under xvfb-run or some other method of guaranteeing it has an Xorg display. This would have solved a number of Gentoo bugs with missing runtime dependencies or sed lines that malfunctioned when the code they patched no longer applied, but the sed lines themselves began to remove code that the package maintainers never intended it to remove (using patch instead of sed would also help here).

Originally Posted by brainiacghost

I think that's a little harsh, there was a bit of a miscommunication, combined with perhaps not responding well to antagonistic tone. The other thing is that other packages that depend on PyQt didn't seem to have build failures, so it made sense to initially seek out the issue here. It does take slightly longer than a day sometimes to try and figure out the issue with an unfamiliar build system particularly when no one on this thread is actually one of the gentoo devs / maintainers. As it happens I'd already figured out the issue and was working on a solution when you replied.

Well, to be fair this one didn't either, not if you used sip-4 to build calibre.

But really, distros have had since https://github.com/kovidgoyal/calibr...54da9de9267025 to figure out the issue with the build system, and Gentoo has been dealing with it by reverting the change until further notice, the entire time.

Originally Posted by brainiacghost

I agree, it isn't his job (or yours), or anyone's really, and we are all entitled to respond to issues in the way we want to, but perhaps stepping back and thinking about how things could be percieved prior to hitting send could go a long way towards encouraging people to find their own solutions and contributing them back to the community.

I do appreciate that there is relevent information in both yours and Kovid's posts, and I don't want this to come across as me being ungrateful - I know that it's no one's job except the relevent package maintainer to sort out build issues like this, but one of the first things I do when debugging an issue (after trying the obvious) is ask to see if anyone else has had a similar issues, and the calibre development forum seems an appropriate place to do this given google searches were coming up with zilch.

Sure, and as I said I can totally understand the original question. Maybe not everyone was thrilled to be told "if you are using one of those silly distros that split packages into dev and non dev versions" or "You will need to figure out just how gentoo has butchered their pyqt packaging" (at least at that point, I would not have phrased it as such), but ultimately some useful starting information was there.

Because I would like to see this fixed, I have provided additional information, but again, you might think that the calibre development forum is an appropriate place to do this, but I posit that the PyQt support channel is also an appropriate place to do this...

... and it becomes an even better place to do it, once the calibre developer claims that it's a sip/pyqt problem and not a calibre one. At that point, it inevitably becomes a bit of a battle of wills to see who will crack first, the questioners who may end up going to upstream PyQt or the application developer who may end up contributing time in researching and debugging a distro's unrelated dependency problems.

Not super fun, I suppose, given as far as the application developer is concerned, he provided all the information he had, and told you exactly which component you need to look into to fix it.

Originally Posted by brainiacghost

For reference, the PyQt5 ebuild used a deprecated build system (I'm unsure when it changed from configure.py to sip-build, as old versions of the PyQt5 documentation mentions configure.py), that required updating. Additionally, not all of the flags passed to the old build system directly translated across so there needed to be a little bit of tinkering with configuration flags to ensure that PyQt5 would build properly. Once that's updated in the main portage tree, a calibre ebuild for the latest version (5.24.0) will build OK and the zeroconf errors that were also happening due to a zeroconf update have been fixed thanks to Kovid's dependencies being updated.

Arch switched to sip-build for PyQt5 back in December 2019, and I seem to recall but can't swear to it that the initial sip-build version also deprecated the configure.py method. It was supposed to be compatible with sip-4 anyway, so it should be possible to continue building sip-4 programs using a version of PyQt that got built via sip-build. You might need to do an ABI rebuild with no code changes on all reverse dependencies... it took about a year for calibre to follow PyQt5 and use sip-5's "sip-build" program, during which time it continued to work fine invoking the "sip" tool from sip-4.

Anyway.

Upstream PyQt is the best place to ask about those configuration flags. Really. PLEASE, do ask the PyQt developer about this, he created sip-build and it's his $DAYJOB to support it. If the option doesn't exist, and you need it, then you will need to ask him to add it back anyway. He's not unapproachable.

While you're at it, you could ask about any issues you're having with PyQt.

EDIT: actually I see you have already asked about this on the mailing list. Sorry.

[akadaedalus]

I also find it strange that my post was used as an example of "interrogation" . I responded to an error report and an answer to use a -devel package which does not apply to my silly distro despite the exact same error.

Thanks for the the work on this everyone. I had no idea it went this deep into pyqt5 build scripts. Despite my computer science degree and software development career I never took the time to learn and develop in Python. It remains enigmatic to me.

Take it easy. Cheers.