On Fri, Mar 4, 2022 at 7:19 AM Leo Famulari 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
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
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,
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,
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
-- Forwarded message -
From: Jacob MacDonald
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
On Fri, Feb 18, 2022 at 10:28 PM Leo Famulari wrote:
> Can you keep trying and let us k
-- Forwarded message -
From: Leo Famulari
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
In general, when bisecting a range of commits that includes merge
commits, you should use
-- Forwarded message -
From: Jacob MacDonald
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
On Thu, Feb 17, 2022 at 5:41 PM Leo Famulari wrote:
> Did you check if this bug has b
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
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
daemon/system restarts*
I've been able to reproduce it consistently across multiple Guix versions
and after daemon/system. Seems like a bug in my install but not sure where
since my Guix binaries are from the substitute. Probably a better thread
for help-guix, thanks for the help!
Yes, though interestingly I can't reproduce in a development tree at
the commit used when I submitted the report
(9f9520a1299fccd8508d03ce0c9280c6e0030207). In summary:
Error occurs:
1. In 9f9520a1299fccd8508d03ce0c9280c6e0030207
2. In 00386d3430f12710997f17091a55c07323ff138c
3. In
Noticed the problem with cl-slime-swank, but seems to happen with a
variety of packages including sbcl-cl-uglify-js itself. I checked
javascript.scm, which does import lisp-xyz; Haven't done any deeper
debugging to discover possible causes.
Backtrace follows.
$ guix package
> I believe this should be fixed by 83aa656217.
That does indeed fix both bugs. In my specific case I'm still running
into an issue with dependency shadowing, but it seems like a separate
issue and I'll open a new one if it's not on my side.
Thanks.
To reproduce, just guix environment --ad-hoc ghc -- ghci. ghc@8.4.3
works. Seems like this may be related to some Prelude changes upstream
(https://gitlab.haskell.org/ghc/ghc/issues/16563), but I'm not
familiar enough with GHC internals to really tell what's going on.
Interestingly, when I try to
I noticed this bug a while back but didn't think to submit it to
debbugs and didn't make the connection to the 2->3 transition. Happy
to help you hunt this one, and may take a look in that direction now
that you've set me on an unexplored path.
17 matches
Mail list logo
