[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.