bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Jacob MacDonald]

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.

bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Leo Famulari]

On Thu, Feb 17, 2022 at 01:05:09AM -0600, Jacob MacDonald wrote:
> 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.

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?

https://calibre-ebook.com/bugs

bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Jacob MacDonald]

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.

bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Leo Famulari]

On Sat, Feb 19, 2022 at 09:39:52PM -0600, Jacob MacDonald wrote:
> 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.

That's fine with me.

bug#54033: Fwd: bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Jacob MacDonald]

---------- Forwarded message ---------
From: Jacob MacDonald <jaccarmac@gmail.com>
Date: Fri, Feb 18, 2022 at 8:52 PM
Subject: Re: bug#54033: Calibre's ebook-viewer only shows
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:
> Did you check if this bug has been reported upstream?

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?

bug#54033: Fwd: bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Jacob MacDonald]

---------- Forwarded message ---------
From: Leo Famulari <leo@famulari.name>
Date: Fri, Feb 18, 2022 at 10:28 PM
Subject: Re: bug#54033: Calibre's ebook-viewer only shows
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:
> On Thu, Feb 17, 2022 at 5:41 PM Leo Famulari <leo@famulari.name> wrote:
>> Did you check if this bug has been reported upstream?
>
> 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?

bug#54033: Fwd: bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Jacob MacDonald]

---------- Forwarded message ---------
From: Jacob MacDonald <jaccarmac@gmail.com>
Date: Sat, Feb 19, 2022 at 2:13 PM
Subject: Re: bug#54033: Calibre's ebook-viewer only shows
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:
> Can you keep trying and let us know the results?

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.

> In general, when bisecting a range of commits that includes merge commits, you should use the --first-parent option

Thanks again for the bisect help. That made the search much narrower
and the builds far easier.

Jacob.

bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Jacob MacDonald]

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.

bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Jacob MacDonald]

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.

bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Jacob MacDonald]

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?

bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Jacob MacDonald]

Jesse wrote:
> I do not know if this is specific to guix or a problem generally with Calibre 5.36.

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.

bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Leo Famulari]

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:
> Jesse wrote:
>> I do not know if this is specific to guix or a problem generally with Calibre 5.36.
>
> 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.

bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Jacob MacDonald]

On Fri, Mar 4, 2022 at 7:19 AM Leo Famulari <leo@famulari.name> wrote:
> I think we'll have to fix this bug the old-fashioned way: ... debugging

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.

> reporting it upstream

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.

bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

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:
--8<---------------cut here---------------start------------->8---
QTWEBENGINE_CHROMIUM_FLAGS="--enable-logging -v=1" ebook-viewer
QTWEBENGINE_CHROMIUM_FLAGS="--enable-logging -v=1" FreeCAD
--8<---------------cut here---------------end--------------->8---

In both cases the same error message was printed several times:
--8<---------------cut here---------------start------------->8---
[7052:1:0304/150130.882217:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed
--8<---------------cut here---------------end--------------->8---

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[bdju via Bug reports for GNU Guix]

On Fri Mar 4, 2022 at 8:07 AM CST, Guillaume Le Vaillant 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.

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

bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

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

> On Fri Mar 4, 2022 at 8:07 AM CST, Guillaume Le Vaillant 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.
>
> qutebrowser and anki are also affected. There's an issue somewhere about
> it already.

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

So the text is rendered correctly when using:
--8<---------------cut here---------------start------------->8---
QTWEBENGINE_CHROMIUM_FLAGS="--no-sandbox" ebook-viewer
QTWEBENGINE_CHROMIUM_FLAGS="--no-sandbox" calibre
QTWEBENGINE_CHROMIUM_FLAGS="--no-sandbox" FreeCAD
--8<---------------cut here---------------end--------------->8---

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]