Summary: | app-text/calibre: rekeyword | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Eli Schwartz <eschwartz93> |
Component: | Keywording | Assignee: | Zac Medico <zmedico> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | eschwartz93, ionen, qt |
Priority: | Normal | Keywords: | CC-ARCHES |
Version: | unspecified | Flags: | nattka:
sanity-check-
|
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: |
app-text/calibre *
dev-lang/rapydscript-ng ^
dev-python/unrardll ^
dev-qt/qtimageformats ^
dev-python/PyQt6 ^
dev-python/PyQt6-WebEngine ^
|
Runtime testing required: | --- |
Bug Depends on: | 914026 | ||
Bug Blocks: |
Description
Eli Schwartz
2023-11-08 19:43:37 UTC
Unable to check for sanity:
> package masked: app-text/calibre-6.29.0, in all profiles for arch: arm x86
Oh huh, this seems to be bug 893234 RIP? Not sure what I should do here. In addition to the webengine-based masking, it seems some Qt 6 packages were not available yet, and I didn't notice due to being distracted by the packages I myself added. :D Unable to check for sanity:
> package masked: app-text/calibre-7.0.0, in all profiles for arch: arm x86
Unable to check for sanity:
> package masked: app-text/calibre-7.1.0, in all profiles for arch: arm x86
hm, I suppose it doesn't really strictly depend on bug 914026 as-is, but dunno how we want to handle it. I don't tend to like changing package lists mid-way through. Erm, that means qtwebengine:6 for x86 and arm, do we really want to do try this? Wouldn't say if this was arm64. Like I said, I dunno what to do here. In theory, one answer might be bug 669082. This is closed for lack of interest because the binhost will provide gpkg's for use by anyone that wants a bin of qtwebengine... but will that work for x86? I don't know what it takes to get a decent 64-bit toolchain going for the purpose of compiling x86 binpkgs using a linker that has access to reasonable quantities of your system's memory. Is this something that would be easier to do using a carefully rigged local setup in order to produce prebuilt binaries suitable for repackaging in a qtwebengine-bin ebuild? Maybe. Also arm64 is bug 907080 :P Ah sorry, I went a bit over comment #2. While I tried the whole qt stack on x86 in a chroot (to see if tests were fine), I still hadn't even dared try qtwebengine. Generally tend to wonder if we should bother with it even if we can hack our way to make it work. For arm64 I'll be needing it for qutebrowser too, albeit put sorting that out on hold given it still supports qt5 and USE=qt6 is masked (I was hoping bug #914026 would do at least ppc* before look at keywording more packages and starting to unmask USE=qt6, but I guess that's stalled forever). It's masked already on arm/x86 so closing for now as it's not rekeywording and not really sure we're that worried about getting this available again after years right this moment. Can reopen if you want to pursue it though. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8771417fb5bf5e74151422a3d9c3f7ea2d858244 commit 8771417fb5bf5e74151422a3d9c3f7ea2d858244 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-11-29 06:04:23 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-11-29 06:05:27 +0000 app-text/calibre: drop stale ~arm, ~x86 keywords calibre is masked because qtwebengine is masked on arm & x86, so these keywords weren't doing anything anyway and were just misleading at this point (giving the appearance of dropped kws). Bug: https://bugs.gentoo.org/917044 Signed-off-by: Sam James <sam@gentoo.org> app-text/calibre/calibre-5.44.0-r2.ebuild | 2 +- app-text/calibre/calibre-5.44.0-r3.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Thanks, that change seems logical to me. I only opened this rekeyword bug out of a sense of obligation ;) I have no actual stake in it. |