Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

Calibre's main window is unaffected, but it's impossible to read any

EPUBs in the viewer. The text in both the book and the settings is

affected. Images show up.

I don't remember if I noticed this before or after the bit QtWebKit

removal a few weeks ago. It would be a strange root cause but is the

only thing I can see that makes sense temporally.

On Thu, Feb 17, 2022 at 01:05:09AM -0600, Jacob MacDonald wrote:

You can find out for sure by testing Calibre from before that change:

`guix time-machine --commit=262a1734e250f756471a066348381017b3e281d6 -- shell calibre`

... because that commit 262a1734 immediately preceded the removal of

Calibre's transitive dependency on QtWebKit.

Well, I tested an old copy of Calibre myself, from around January 7, and

it doesn't help with this bug. Did you check if this bug has been

reported upstream?

I realize that the conversation has been continuing outside the bug tracker.

9d25ee30b188f9202cc14f7cd25ba8a1c3ec1a72 has a working version of

Calibre 5.21.0. 6dffced09ecda024e0884e352778c221ad066fd6 is the commit

where it broke. That's a big merge commit, and Calibre is only broken

in one of the parents. I started to do a bisect between the bad parent

and the commit which bumped Calibre's version, but it contains merges

and --first-parent seems to be less useful there than in the earlier

bisect session. I see a recent update to Calibre 5.36.0, but I'm

taking a pause because waiting for QtWebKit to build is annoying.

That is the summary of what I know now; I'm also happy to copy the

rest of the emails back into this thread, with Leo's permission.

Jacob.

On Sat, Feb 19, 2022 at 09:39:52PM -0600, Jacob MacDonald wrote:

That's fine with me.

---------- Forwarded message ---------

white-on-white or dark-on-dark.

To: Leo Famulari <leo@famulari.name>

On Thu, Feb 17, 2022 at 5:41 PM Leo Famulari <leo@famulari.name> wrote:

I gave the Launchpad a cursory check but wasn't able to find what I

was looking for.

In addition, I scrolled back through the Git history a ways and found

a commit that seems to have working Calibre at the same version.

$ guix time-machine --commit=9d25ee30b188f9202cc14f7cd25ba8a1c3ec1a72

-- package --show=calibre

name: calibre

version: 5.21.0

,,,

$ guix time-machine --commit=9d25ee30b188f9202cc14f7cd25ba8a1c3ec1a72

-- shell calibre -- ebook-viewer

brings up a working version of the reader.

Thank you for the information about the time-machine command.

I started to do a Git bisect on my copy of the repository, but found

that it was intractable to build the versions of Guix necessary. Part

of that seems to be related to some merges: Some of the candidate

commits had dates from 2020 on them and the candidate set was rather

large. Is there a smarter way to hunt down the commit where Calibre

broke?

---------- Forwarded message ---------

white-on-white or dark-on-dark.

To: Jacob MacDonald <jaccarmac@gmail.com>

In general, when bisecting a range of commits that includes merge

commits, you should use the --first-parent option, which basically

does the right thing with the merge when choosing commits to test.

Can you keep trying and let us know the results? If it becomes

infeasible, let us know and we can arrange to run the bisection next

week (on vacation).

Calibre is one of the flagship free software applications so let's

work together to fix it :)

On Fri, Feb 18, 2022, at 21:52, Jacob MacDonald wrote:

---------- Forwarded message ---------

white-on-white or dark-on-dark.

To: Leo Famulari <leo@famulari.name>

On Fri, Feb 18, 2022 at 10:28 PM Leo Famulari <leo@famulari.name> wrote:

As luck would have it, bisecting the smaller set gives me

6dffced09ecda024e0884e352778c221ad066fd6 as the first bad commit. And

that's the big merge. I'm guessing that the next step is to bisect

some subset of what used to be core-updates-frozen, but I have not

gotten there yet.

Thanks again for the bisect help. That made the search much narrower

and the builds far easier.

Jacob.

The substitutes to install Calibre 5.36 updated, so I gave it a try

today. The issue exists there too, suggesting further that the problem

is in the dependencies somewhere. I haven't come across a working

revision with Calibre 5.14 in my bisecting expeditions yet, but I

suspect some of those would be broken in the same way.

Bisecting the branch which used to be core-updates-frozen with

--first-parent has so far been fruitless. I seem to be jumping dates

and Calibre versions again, and my Git-fu isn't strong enough to

narrow the range of commits I'm bisecting. Many of the commits from

core-updates-frozen also appear to be unbuildable; I'm not sure if

that's expected, my guix-daemon being too new, or something else.

I'm looking at merges *from* master into core-updates and

core-updates-frozen pre-6dffce as potential problem sites.

Based on the diff between the working and broken parents of 6dffce, my

hunch is that the regression lies in a dependency (likely something on

the Qt side) as opposed to the Calibre recipe itself.

After looking into what I think was core-updates(-frozen), I am

running into a wall in the form of glib-networking, which blocks my

attempts to build Calibre on many commits. However, I did find another

merge which may be of interest:

b029be2ee0f81cdcbc14240ff426408085ab0a40. One side of it,

ffb381856d0c6cc1a557b789f6b377cfa17002a0, contains a working version

of Calibre 5.21. I can't verify that the other side fails due to the

mentioned glib-networking blocker. However, the common ancestor of the

commits in question is 8b1bde7bb3936a64244824500ffe60f123704437, which

has an older but still working version of Calibre: 5.14. I'm out of

ideas for the moment: The differences in the Calibre recipe between

branches are very small, but I don't know how to bisect here more

effectively, get the core-updates-frozen commits to build, or dig into

the Python build process.

My description of the bug was hasty. The viewer is still broken in the

same way, but I realize now that the text is not invisible or

unselectable. Rather, selection still works but only displays

selection markers at the upper left corner of the screen. According to

a bug report about Calibre, similar things can happen if the fonts are

not properly installed

(https://www.mobileread.com/forums/showthread.php?t=315146).However,

I checked a working version and broken version of my Guix profile

against one another and the fonts appear to be installed correctly in

both trees.

While doing that, I also noticed that __pycache__ directories only

exist in the broken tree. Is that a signal of something going wrong or

just a change in Guix's Python?

merge 54121 54033

Jesse wrote:

As far as I can tell, it's a problem introduced by Guix, as I noticed

it occurring with Calibre 5.21. For what it's worth, I have the latest

working version that I can find installed.

guix time-machine --commit=b603554ed044638dd40b6863d5dada59eefe03b8 --

package -i calibre

Leo:

I've continued to attempt the last bisect I mentioned, but I'm bogged

down by repeated build errors that force me to skip more commits than

I can test. Is there a trick to building the commits which got merged

in; Do they not work with time-machine? The errors I'm seeing are of

the form:

guix time-machine: error: You found a bug: the program

'/gnu/store/mqhfdbrl834biajwq667fzsck344g09s-compute-guix-derivation'

failed to compute the derivation for Guix (version:

"b2b799e2d8330af934f48bf66afb5114addb4dd7"; system: "x86_64-linux";

host version: "1af78ab5e80b98d1914b85709c60fa7f9782e1db"; pull-version: 1).

Please report it by email to <bug-guix@gnu.org>.

That latest failure seems to be related to tcsh, but that's not the

only derivation which has failed for me in the same way.

It's not easy (perhaps impossible) to bisect the core-updates branch. That's because most commits on the branch are not expected to build. For most of the branch's lifetime, it's merely a place to dump patches that cause rebuilds of the entire distro (e.g. a glibc update). It's only in the final stages of the core-updates cycle that we integrate those core changes into a working codebase.

I think we'll have to fix this bug the old-fashioned way: debugging, or reporting it upstream.

On Thu, Mar 3, 2022, at 23:07, Jacob MacDonald wrote:

Hi,

FreeCAD also has some issues with the rendering of its "start page"

where the text is missing.

And as Calibre and FreeCAD are apparently both Python applications using

QtWebEngine, it may indicate that there is something not working

correctly in QtWebEngine or in the Python bindings to QtWebEngine.

I tried printing some debug traces with:

In both cases the same error message was printed several times:

But so far I don't know what it means, or even if it's related to the

rendering issue...

On Fri, Mar 4, 2022 at 7:19 AM Leo Famulari <leo@famulari.name> wrote:

I tried a little stracing, which didn't illuminate anything.

The results of my attempt at diffing are described above; I intend to

try modifying the build steps, but if there's any advice for debugging

Python builds I'll gladly accept it.

The changes to the Python build system between the working commit and

the broken merge seem moderate, but I've only skimmed them. I haven't

dived into changes to dependencies yet.

When I installed the working version as described above, my desktop

shortcut stayed broken until I relogged or started it from a fresh

terminal. This seems like an environment issue to me, but the desktop

files didn't change in relevant ways.

Given the similarity in the breakage over versions, it seems unlike an

upstream bug to me. The only similar issue I can find is the font one,

and the fonts are properly installed in the broken tree.

On Fri Mar 4, 2022 at 8:07 AM CST, Guillaume Le Vaillant wrote:

qutebrowser and anki are also affected. There's an issue somewhere about

it already.

"bdju" <bdju@tilde.team> skribis:

Zhu Zihao found a workaround (see issue 54297): passing "--no-sandbox"

to Chromium.

So the text is rendered correctly when using: