Created attachment 713364 [details] build log build log in attachment
Created attachment 713367 [details] emerge info
Created attachment 713370 [details] emerge -pqv
I get the same result, I emerge two packages with sip, but no difference.. I will send my build log
Created attachment 713649 [details] build log
Created attachment 713664 [details, diff] app-text/calibre: support SIP v5 If someone with ">=dev-python/sip-5" could test this patch then I'll go ahead and merge it. https://github.com/gentoo/gentoo/pull/21122
With latest portage snapshot, calibre-5.16.1 installed without any error. Don't know what was the difference between the time I reported this bug and now.
I have sip-4 installed, but now I will upgrade to sip-5. I will leave the feedback here, but suppose I would need Zac Medico PR changes.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cc35e31c02fb8baaee555f0d4033be58dd62363d commit cc35e31c02fb8baaee555f0d4033be58dd62363d Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2021-06-04 19:28:19 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2021-06-14 18:02:27 +0000 app-text/calibre: support SIP v5 Closes: https://bugs.gentoo.org/793986 Package-Manager: Portage-3.0.19, Repoman-3.0.3 Signed-off-by: Zac Medico <zmedico@gentoo.org> app-text/calibre/calibre-5.16.1.ebuild | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=875872c2297b31dd08b3ef11a7f7bb06b96b0edf commit 875872c2297b31dd08b3ef11a7f7bb06b96b0edf Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2021-06-14 19:13:09 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2021-06-14 19:13:50 +0000 app-text/calibre: unpin dev-python/sip version for SIP v5 Bug: https://bugs.gentoo.org/793986 Package-Manager: Portage-3.0.20, Repoman-3.0.3 Signed-off-by: Zac Medico <zmedico@gentoo.org> app-text/calibre/calibre-5.16.1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=11af861c0aa0675c2c58f1f6c7ca506c45c0f64f commit 11af861c0aa0675c2c58f1f6c7ca506c45c0f64f Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2021-06-14 20:45:26 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2021-06-14 20:49:03 +0000 Revert "app-text/calibre: unpin dev-python/sip version for SIP v5" This reverts commit 875872c2297b31dd08b3ef11a7f7bb06b96b0edf. The SIP v5 migration depends on a dev-python/PyQt-builder ebuild requested in bug 796005. Bug: https://bugs.gentoo.org/744958 Bug: https://bugs.gentoo.org/793986 Bug: https://bugs.gentoo.org/796005 Signed-off-by: Zac Medico <zmedico@gentoo.org> app-text/calibre/calibre-5.16.1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
I'm upgrading to PyQt5-5.15.4-r1 now, since calibre fails to build with my installed PyQt5-5.15.2 instance like this: > SIPing 3 files... > /usr/bin/python3.8 -c from sipbuild.tools.build import main; main(); --verbose --no-make --qmake /usr/lib64/qt5/bin/qmake > Querying qmake about your Qt installation... > /usr/lib64/qt5/bin/qmake -query > These bindings will be built: pictureflow. > Generating the pictureflow bindings... > -c: Unable to find file "QtWidgets/QtWidgetsmod.sip" > > > * ERROR: app-text/calibre-5.21.0::gentoo failed (install phase):
With PyQt5-5.15.4-r1, I have /usr/share/sip/PyQt5/QtWidgets/QtWidgetsmod.sip installed, however the calibre build doesn't find it and still fails with the same error as before the PyQt5-5.15.4-r1 upgrade: > SIPing 3 files... > /usr/bin/python3.8 -c from sipbuild.tools.build import main; main(); --verbose --no-make --qmake /usr/lib64/qt5/bin/qmake > Querying qmake about your Qt installation... > /usr/lib64/qt5/bin/qmake -query > These bindings will be built: pictureflow. > Generating the pictureflow bindings... > -c: Unable to find file "QtWidgets/QtWidgetsmod.sip" > > > * ERROR: app-text/calibre-5.21.0::gentoo failed (install phase): This is my current ebuild diff: > --- calibre-5.16.1.ebuild 2021-06-15 09:55:01.962385579 -0700 > +++ calibre-5.21.0.ebuild 2021-06-17 18:48:24.457532898 -0700 > @@ -71,3 +71,3 @@ > >=dev-python/python-dateutil-2.5.3[${PYTHON_MULTI_USEDEP}] > - >=dev-python/PyQt5-5.12[gui,svg,widgets,network,printsupport,${PYTHON_MULTI_USEDEP}] > + >=dev-python/PyQt5-5.15.4-r1[gui,svg,widgets,network,printsupport,${PYTHON_MULTI_USEDEP}] > >=dev-python/PyQtWebEngine-5.12[${PYTHON_MULTI_USEDEP}] > @@ -106,4 +106,5 @@ > $(python_gen_cond_dep ' > + dev-python/PyQt-builder[${PYTHON_MULTI_USEDEP}] > >=dev-python/setuptools-23.1.0[${PYTHON_MULTI_USEDEP}] > - <dev-python/sip-5[${PYTHON_MULTI_USEDEP}] > + >=dev-python/sip-5[${PYTHON_MULTI_USEDEP}] > ') > @@ -127,7 +128,2 @@ > > - if ! has_version ">=dev-python/sip-5"; then > - einfo "Applying SIP v4 patch because SIP v5 was not detected" > - eapply "${WORKDIR}/${PN}-5.16.0-SIP-v4.patch" > - fi > - > eapply_user
Created attachment 716655 [details, diff] diff -U1 calibre-5.16.1.ebuild calibre-5.21.0.ebuild
Dunno if this helps or not, but it's failing to install for me as well: >>> Install app-text/calibre-5.16.1 into /var/tmp/portage/app-text/calibre-5.16.1/image * * Running build * Building 24 extensions SIPing 3 files... /usr/bin/python3.9 -c import os; os.chdir('/var/tmp/portage/app-text/calibre-5.16.1/work/calibre-5.16.1/build/pyqt/pictureflow'); from sipbuild.tools.build import main; main(); --verbose --no-make --qmake /usr/lib64/qt5/bin/qmake -c: Unable to import 'pyqtbuild': No module named 'pyqtbuild' * ERROR: app-text/calibre-5.16.1::gentoo failed (install phase): * (no error message) * * Call stack: * ebuild.sh, line 127: Called src_install * environment, line 2796: Called die * The specific snippet of code: * PATH=${T}/bin:${PATH} PYTHONPATH=${S}/src${PYTHONPATH:+:}${PYTHONPATH} "${PYTHON}" setup.py install --root="${D}" --prefix="${EPREFIX}/usr" --libdir="${EPREFIX}/usr/${libdir}" --staging-root="${ED}/usr" --staging-libdir="${ED}/usr/${libdir}" || die; * Just for the record, I have both sip-4.19.25-r1 and sip-5.5.0-r2 installed, though I have no idea which one it's picking up here.
I had to install PyQt-builder to get past the error "No module named 'pyqtbuild'". I am still struggling to figure out what fixes the error with QtWidgets/QtWidgetsmod.sip . I have both sip-4 and sip-5. It appears the calibre version bump was premature, particularly when there are python upgrades in the works. Maybe don't remove older versions? Anyway, a build dependency on PyQt-builder seems to be required.
Sorry for double post, must have fat fingered the submit button. Pointless "upstream" discussion specific to 5.16.1: http://www.mobileread.mobi/forums/showthread.php?p=4132792#post4132792 Downgrading to PyQt5-5.15.2 did not work. Downgrading to calibre-5.13.0 worked. Moving the portage tree to a git repo was the best idea Gentoo ever had, it saves me time with issues like this. I moved back to PyQt-5.15.4-r1 and calibre-5.13.0 still built. I removed PyQt-builder and calibre-5.13.0 still built. I recommend masking calibre-5.16.1 and restoring calibre-5.13.0 until this is resolved. Please add PyQt-builder dependencies to future ebuilds. As an aside, I've had run-ins with the developer before saying he tends to go a little too bleeding-edge with his feature bloat but he doesn't care. He uses his binary distribution as justification. Thanks for your continued support.
I tried to compile 5.13.0 which is apparently what I was using before and after portage reinstalled several packages to python3.8 I get the error: Installing calibre environment module: /var/tmp/portage/app-text/calibre-5.13.0/image/usr/lib/python3.8/site-packages/init_calibre.py Traceback (most recent call last): File "setup.py", line 119, in <module> sys.exit(main()) File "setup.py", line 104, in main command.run_all(opts) File "/var/tmp/portage/app-text/calibre-5.13.0/work/calibre-5.13.0/setup/__init__.py", line 203, in run_all self.run_cmd(self, opts) File "/var/tmp/portage/app-text/calibre-5.13.0/work/calibre-5.13.0/setup/__init__.py", line 199, in run_cmd cmd.run(opts) File "/var/tmp/portage/app-text/calibre-5.13.0/work/calibre-5.13.0/setup/install.py", line 150, in run self.run_postinstall() File "/var/tmp/portage/app-text/calibre-5.13.0/work/calibre-5.13.0/setup/install.py", line 173, in run_postinstall from calibre.linux import PostInstall File "/var/tmp/portage/app-text/calibre-5.13.0/work/calibre-5.13.0/src/calibre/linux.py", line 13, in <module> from calibre.customize.ui import all_input_formats File "/var/tmp/portage/app-text/calibre-5.13.0/work/calibre-5.13.0/src/calibre/customize/ui.py", line 18, in <module> from calibre.customize.builtins import plugins as builtin_plugins File "/var/tmp/portage/app-text/calibre-5.13.0/work/calibre-5.13.0/src/calibre/customize/builtins.py", line 752, in <module> from calibre.devices.smart_device_app.driver import SMART_DEVICE_APP File "/var/tmp/portage/app-text/calibre-5.13.0/work/calibre-5.13.0/src/calibre/devices/smart_device_app/driver.py", line 2044, in <module> from zeroconf import (BadTypeInNameException, _HAS_A_TO_Z, ImportError: cannot import name '_HAS_A_TO_Z' from 'zeroconf' (/usr/lib/python3.8/site-packages/zeroconf/__init__.py) * ERROR: app-text/calibre-5.13.0::local_ebuilds failed (install phase)
(In reply to John Covici from comment #18) > I tried to compile 5.13.0 which is apparently what I was using before and > after portage reinstalled several packages to python3.8 I get the error: > > Installing calibre environment module: > /var/tmp/portage/app-text/calibre-5.13.0/image/usr/lib/python3.8/site- > packages/init_calibre.py > Traceback (most recent call last): > File "setup.py", line 119, in <module> > sys.exit(main()) > File "setup.py", line 104, in main > command.run_all(opts) > File > "/var/tmp/portage/app-text/calibre-5.13.0/work/calibre-5.13.0/setup/__init__. > py", line 203, in run_all > self.run_cmd(self, opts) > File > "/var/tmp/portage/app-text/calibre-5.13.0/work/calibre-5.13.0/setup/__init__. > py", line 199, in run_cmd > cmd.run(opts) > File > "/var/tmp/portage/app-text/calibre-5.13.0/work/calibre-5.13.0/setup/install. > py", line 150, in run > self.run_postinstall() > File > "/var/tmp/portage/app-text/calibre-5.13.0/work/calibre-5.13.0/setup/install. > py", line 173, in run_postinstall > from calibre.linux import PostInstall > File > "/var/tmp/portage/app-text/calibre-5.13.0/work/calibre-5.13.0/src/calibre/ > linux.py", line 13, in <module> > from calibre.customize.ui import all_input_formats > File > "/var/tmp/portage/app-text/calibre-5.13.0/work/calibre-5.13.0/src/calibre/ > customize/ui.py", line 18, in <module> > from calibre.customize.builtins import plugins as builtin_plugins > File > "/var/tmp/portage/app-text/calibre-5.13.0/work/calibre-5.13.0/src/calibre/ > customize/builtins.py", line 752, in <module> > from calibre.devices.smart_device_app.driver import SMART_DEVICE_APP > File > "/var/tmp/portage/app-text/calibre-5.13.0/work/calibre-5.13.0/src/calibre/ > devices/smart_device_app/driver.py", line 2044, in <module> > from zeroconf import (BadTypeInNameException, _HAS_A_TO_Z, > ImportError: cannot import name '_HAS_A_TO_Z' from 'zeroconf' > (/usr/lib/python3.8/site-packages/zeroconf/__init__.py) > * ERROR: app-text/calibre-5.13.0::local_ebuilds failed (install phase) That's https://bugs.gentoo.org/800233 ... We're quite well served with calibre build problems atm...
> I have both sip-4 and sip-5 calibre's ebuild depends on sip-4, seemingly, but https://gitweb.gentoo.org/repo/gentoo.git/commit/app-text/calibre?id=cc35e31c02fb8baaee555f0d4033be58dd62363d caused the ebuild to use sip-5 if it happened to be installed as an unannounced dependency because other applications used it. Meanwhile the actual fix for this bug was commit https://gitweb.gentoo.org/repo/gentoo.git/commit/app-text/calibre?id=d929291be3262b89b522d1ef0c209fe57158131e This then failed because: - using sip-5 isn't enough, you need to use PyQt-builder too but the if/elsed code building against an unannounced sip-5 DEPEND which wasn't in DEPEND didn't take that into account - using sip-5 requires fixing bug 805965 first, ideally as part of exploring the distro-wide upgrade to sip-5. My understanding is, you can't build sip-5 applications against components using sip-4. It seems like the ebuild should never have included if/elsed code to build against something that wasn't in the DEPEND list and was never actually tested, but merged after requests for testing failed to elicit feedback. Don't you have USE flags for this?
calibre-5.24.0 compilation fails with: > Unable to import 'pyqtbuild': No module named 'pyqtbuild' E.g., calibre-5.24.0 ebuild still needs patch to add dev-python/PyQt-builder into dependency list.
calibre-5.24.0 compilation fails with error: > Unable to find file "QtWidgets/QtWidgetsmod.sip" Packages installed: - dev-python/PyQt-builder-1.10.3 - dev-python/PyQt5-5.15.4-r1 - dev-python/PyQt5-sip-12.9.0 - dev-python/PyQtWebEngine-5.15.4
For users still suffering breakage, here's the tl;dr: 1. Unmask unstable Calibre, PyQt-builder, PyQt5, PyOt5-sip, and sip:5 ebuilds: $ cat <<EOF >>/etc/portage/package.accept_keywords ~app-text/calibre-5.25.0-r2 ~dev-python/PyQt-builder-1.10.3 ~dev-python/PyQt5-5.15.5_pre2107091435 ~dev-python/sip-6.2.0_pre2108241238 EOF 2. Manually emerge all of the above: $ emerge calibre PyQt-builder PyQt5 PyOt5-sip sip:5 For Gentoo developers, here's the tl;dr: 1. The "stable" dev-python/PyQt5-5.15.4-r1 ebuild is fundamentally broken *AND SHOULD BE IMMEDIATELY REMOVED FROM THE PORTAGE TREE.* No, really. That ebuild is substantially less stable than the "unstable" dev-python/PyQt5-5.15.5_pre2107091435 ebuild, which actually behaves as expected. What the...? Let me now explicate. Gentoo's PyQt5 build process has been subtly broken for the past two years, but nobody on our side noticed because PyQt5 has continued shipping two parallel build systems -- only one of which reliably works: * A broken sip 4-based build system managed by a deprecated "./configure" script, which our broken PyQt5 ebuilds continued using because we didn't know any better. This includes the "stable" dev-python/PyQt5-5.15.4-r1 ebuild -- which, of course, is anything but stable. Now we know. And knowledge is half the battle, right? * A working sip 5-based build system, which only the "unstable" dev-python/PyQt5-5.15.5_pre2107091435 ebuild currently uses. 2. The "stable" app-text/calibre-5.16.1-r1 ebuild is also fundamentally broken *AND SHOULD BE IMMEDIATELY REMOVED FROM THE PORTAGE TREE.* No, really. That ebuild is also substantially less stable than the "unstable" dev-python/calibre-5.25.0-r2 ebuild, which actually behaves as expected. What the...? Again, the reason is similar. The "stable" calibre ebuild erroneously: * Omits a mandatory build-time and runtime dependency on dev-python/PyQt-builder. * Attempts to concurrently support both the obsolete sip 4-based build system employed by older broken PyQt5 ebuilds (like the "stable" dev-python/PyQt5-5.15.4-r1 ebuild) *AND* the working sip 5-based build system employed by newer working PyQt5 ebuilds (like the "unstable" dev-python/PyQt5-5.15.5_pre2107091435 ebuild). Unsurprisingly, this black magic fails with spectacular fireworks. The "unstable" dev-python/calibre-5.25.0-r2 ebuild resolves both of these issues. It also works. Would someone mind submitting a Portage PR resolving this issue by removing the non-working "stable" ebuilds of both Calibre and PyQt5? Since official devs are out-to-lunch on this one, we'll have to roll up our greasy neckbeard collars and get this done ourselves. If Gentoo wasn't so short on enthusiastic volunteer manpower, I'd publicly call for heads (and Portage privileges) to roll into a bloody hand-woven guillotine basket. Like, seriously. This sort of open shoddiness is embarrassing. Come on! It reflects poorly on the entire distro and source-based methodology. The upstream Calibre dev even excoriated us about our broken PyQt5 and Calibre ebuilds across several upstream issues -- and he was entirely right. You know it's bad when the packages you're packaging openly mock your distro. But we are short on enthusiastic volunteer manpower... so let's not persecute anyone, even if they justifiably deserve to be culled. Instead, let's reflect on how and why our QA has gotten so bad that we can no longer even reliably package core Python dependencies. ** TL;DR ** Unstable ebuilds are stable. Stable ebuilds are broken. Remove stable ebuilds. Emerge unstable ebuilds. Calibre will work. I now sigh.
Addendum: in addition to everything noted above, users also need to unmask and manually install the unstable "dev-python/dev-python/PyQtWebEngine-5.15.5_pre2108100905" ebuild. If you don't, you'll be hit by the following non-human-readable CLI error at Calibre runtime on attempting to view (i.e., read) any book: *** stack smashing detected ***: terminated The Qt WebEngine Render process crashed with termination type: 1 and exit code: 64000 Restarting Qt WebEngine Whenever that occurs, Qt WebEngine fails to restart (of course) and the Calibre Reader silently fails to render the book. *shrug*
(In reply to Cecil Curry from comment #23) > For users still suffering breakage, here's the tl;dr: > > 1. Unmask unstable Calibre, PyQt-builder, PyQt5, PyOt5-sip, and sip:5 > ebuilds: > > $ cat <<EOF >>/etc/portage/package.accept_keywords > ~app-text/calibre-5.25.0-r2 > ~dev-python/PyQt-builder-1.10.3 > ~dev-python/PyQt5-5.15.5_pre2107091435 > ~dev-python/sip-6.2.0_pre2108241238 > EOF > > 2. Manually emerge all of the above: > > $ emerge calibre PyQt-builder PyQt5 PyOt5-sip sip:5 > > For Gentoo developers, here's the tl;dr: > > 1. The "stable" dev-python/PyQt5-5.15.4-r1 ebuild is fundamentally broken > *AND SHOULD BE IMMEDIATELY REMOVED FROM THE PORTAGE TREE.* > > No, really. That ebuild is substantially less stable than the "unstable" > dev-python/PyQt5-5.15.5_pre2107091435 ebuild, which actually behaves as > expected. What the...? Let me now explicate. Gentoo's PyQt5 build process > has been subtly broken for the past two years, but nobody on our side > noticed because PyQt5 has continued shipping two parallel build systems -- > only one of which reliably works: > > * A broken sip 4-based build system managed by a deprecated "./configure" > script, which our broken PyQt5 ebuilds continued using because we didn't > know any better. This includes the "stable" dev-python/PyQt5-5.15.4-r1 > ebuild -- which, of course, is anything but stable. Now we know. And > knowledge is half the battle, right? > * A working sip 5-based build system, which only the "unstable" > dev-python/PyQt5-5.15.5_pre2107091435 ebuild currently uses. > > 2. The "stable" app-text/calibre-5.16.1-r1 ebuild is also fundamentally > broken *AND SHOULD BE IMMEDIATELY REMOVED FROM THE PORTAGE TREE.* > > No, really. That ebuild is also substantially less stable than the > "unstable" dev-python/calibre-5.25.0-r2 ebuild, which actually behaves as > expected. What the...? Again, the reason is similar. The "stable" calibre > ebuild erroneously: > > * Omits a mandatory build-time and runtime dependency on > dev-python/PyQt-builder. > * Attempts to concurrently support both the obsolete sip 4-based build > system employed by older broken PyQt5 ebuilds (like the "stable" > dev-python/PyQt5-5.15.4-r1 ebuild) *AND* the working sip 5-based build > system employed by newer working PyQt5 ebuilds (like the "unstable" > dev-python/PyQt5-5.15.5_pre2107091435 ebuild). Unsurprisingly, this black > magic fails with spectacular fireworks. > > The "unstable" dev-python/calibre-5.25.0-r2 ebuild resolves both of these > issues. It also works. > > Would someone mind submitting a Portage PR resolving this issue by removing > the non-working "stable" ebuilds of both Calibre and PyQt5? Since official > devs are out-to-lunch on this one, we'll have to roll up our greasy > neckbeard collars and get this done ourselves. I'm no expert on Qt or anything related to it, so I'm reluctant to meddle. I've CC'd qt@ because pesa or somebody else might be able to understand the issue here. > > If Gentoo wasn't so short on enthusiastic volunteer manpower, I'd publicly > call for heads (and Portage privileges) to roll into a bloody hand-woven > guillotine basket. Like, seriously. This sort of open shoddiness is > embarrassing. Come on! It reflects poorly on the entire distro and > source-based methodology. The upstream Calibre dev even excoriated us about > our broken PyQt5 and Calibre ebuilds across several upstream issues -- and > he was entirely right. You know it's bad when the packages you're packaging > openly mock your distro. > It's not really helpful to make comments like this. And fwiw, the Calibre maintainer in Gentoo has been away for some time as he needed some time. I'm sorry that there's bugs in packages, and of course we want to fix them, but making angry comments like this is just upsetting and counterproductive. You'd also do well to actually link to issues so we can address them. > But we are short on enthusiastic volunteer manpower... so let's not > persecute anyone, even if they justifiably deserve to be culled. Instead, > let's reflect on how and why our QA has gotten so bad that we can no longer > even reliably package core Python dependencies. > Or maybe there's just a bug in a few packages? Please stop being so rude. The bug tracker is for bugs and for discussing how to solve them, not for you to rant. We welcome more help and comments like this don't really help any developer's motivation. > Unstable ebuilds are stable. Stable ebuilds are broken. Remove stable > ebuilds. Emerge unstable ebuilds. Calibre will work. I now sigh. Leave this out, thanks. The information that the ~arch versions are working _is_ helpful, and all you really needed to say.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fd9d73b28e96631a98b505ac084180d0b1d6382a commit fd9d73b28e96631a98b505ac084180d0b1d6382a Author: Cecil Curry <leycec@gmail.com> AuthorDate: 2021-10-05 04:56:21 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2021-10-05 04:57:59 +0000 app-text/calibre: Require latest PyQtWebEngine Bug: https://bugs.gentoo.org/793986#c24 Package-Manager: Portage-3.0.26, Repoman-3.0.3 Signed-off-by: Zac Medico <zmedico@gentoo.org> app-text/calibre/calibre-5.25.0-r2.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
> It seems like the ebuild should never have included if/elsed code to build against something that wasn't in the DEPEND list and was never actually tested, but merged after requests for testing failed to elicit feedback. Don't you have USE flags for this? No heads in baskets are required. :) I am not a Gentoo user, so I can't test this, but my understanding is that you can simply revert https://gitweb.gentoo.org/repo/gentoo.git/commit/app-text/calibre?id=cc35e31c02fb8baaee555f0d4033be58dd62363d The root of the problem is that this commit broke a working, if deprecation-filled, package. By moving some vital code into an if block that, when evaluating false, prevented that vital code from being run, which is why it only sometimes broke. This will revert back to the status quo of correctly building deprecated software, and the unstable versions which correctly build not-deprecated software can continue to be masked for mysterious reasons that as a non-Gentoo user I don't comprehend. P.S. Since apparently at least one Gentoo dev is *not* on vacation and present in this ticket, thus available to patch calibre, it would be nice if this helpful advice didn't go entirely ignored. I would venture to say that while being on vacation and no one being available to devote time into developing a fix is understandable... ... ignoring clear analysis and instructions on fixing the problem ***via reverting a bad commit*** is a bit more... unfortunate... and your users could, at least, feel justified in being unhappy even if angrily demanding heads is a counterproductive way of demonstrating that unhappiness. Seriously, reverting a bad commit after someone has analyzed the entire problem for you shouldn't be that hard to do after months of cricket chirping. That doesn't take expert domain knowledge as the primary packager.
(In reply to Eli Schwartz from comment #27) > > It seems like the ebuild should never have included if/elsed code to build against something that wasn't in the DEPEND list and was never actually tested, but merged after requests for testing failed to elicit feedback. Don't you have USE flags for this? > > No heads in baskets are required. :) I am not a Gentoo user, so I can't test > this, but my understanding is that you can simply revert > https://gitweb.gentoo.org/repo/gentoo.git/commit/app-text/ > calibre?id=cc35e31c02fb8baaee555f0d4033be58dd62363d > > The root of the problem is that this commit broke a working, if > deprecation-filled, package. By moving some vital code into an if block > that, when evaluating false, prevented that vital code from being run, which > is why it only sometimes broke. That patch was needed for sip v4 support back when I tested it. I no longer have a sip v4 system to test with, but if someone else can test a fix then I would be happy to apply it.
(In reply to Zac Medico from comment #28) > That patch was needed for sip v4 support back when I tested it. I no longer > have a sip v4 system to test with, but if someone else can test a fix then I > would be happy to apply it. I agree it is needed for sip 4 support! I explained in comment 27, which you are replying to, why I agree... ... and then pointed out that it is not actually being applied. So I *literally* don't understand the reply you gave. It doesn't actually seem to be a response to anything I said. And no, I can't "test a fix", I don't use Gentoo... but now that the issue has been extensively debugged across around a dozen comments, I had sort of assumed you'd have enough information on the topic in order to have the confidence to, well... do this incredibly, horrifyingly controversial change called... ... revert back to a previous ebuild that was known to reliably work. Reverting this broken change (using the command "git revert" should do it) will have the effect of: - removing code that tests if a package that isn't in DEPEND, is installed, and if it is installed, compile against that instead Again, I'm not a Gentoo user, just a calibre contributor. I'm not really knowledgeable about how Gentoo works. I'm surprised and shocked that a Gentoo package is deliberately ignoring its own DEPEND and including special code in the ebuild to deselect the package in DEPEND and compile against ***something else instead*** (which has a different ABI!!!) just because it happens to be installed by accident. My understanding is that this sort of thing is usually supposed to be controlled by USE flags. But hey, for all I know, I'm completely off base, that's a Gentoo tradition, and I should stop arguing against it. If so, then I apologize for interrupting, and I'll remove myself from the conversation. TBH it was probably a bad idea for me to say anything in the first place.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=797e48fc572e31870215cba1559198909ad363f3 commit 797e48fc572e31870215cba1559198909ad363f3 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2021-10-22 05:41:09 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2021-10-22 05:44:34 +0000 app-text/calibre: remove 5.16.1-r1 sipv4 conditional The ebuild explicitly requires sipv4 via DEPEND, and therefore the conditional is inappropriate. Bug: https://bugs.gentoo.org/793986#c29 Reported-by: Eli Schwartz <eschwartz@archlinux.org> Package-Manager: Portage-3.0.28, Repoman-3.0.3 Signed-off-by: Zac Medico <zmedico@gentoo.org> app-text/calibre/calibre-5.16.1-r1.ebuild | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
(In reply to Eli Schwartz from comment #29) > TBH it was probably a bad idea for me to say anything in the first place. Makes sense. Thanks for elaborating! :-)
Thanks. :)
Created attachment 749316 [details] build.log compilation error remains with current portage snapshot: sip: /usr/lib/python3.9/site-packages/PyQt5/bindings//QtCore/QtCoremod.sip:23: syntax error
Created attachment 749319 [details] emerge.info emerge info for previous uploaded build.log
Created attachment 749322 [details] emerge.pqv emerge -pqv for previous uploaded build.log
Solve this issue keyword unmasking ~amd64 calibre 5.31.1.
So, this bug is actually fixed?
(In reply to Samuel Bernardo from comment #36) > Solve this issue keyword unmasking ~amd64 calibre 5.31.1. Correct. (In reply to Andreas Sturmlechner from comment #37) > So, this bug is actually fixed? Yes, I suppose we can close it now.
*** Bug 799365 has been marked as a duplicate of this bug. ***
