<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 15/02/2024 23:28, Karl Kleinpaste
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:758d38e1-a5c5-4d9a-95fe-ee5e6a2ee050@kleinpaste.org">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<font face="FreeSerif">As anyone has seen today who gets
issue/source updates from github, I'm doing a few cleanup things
toward the goal of a release.<br>
<br>
Yes, I've been gone an indecent amount of time again. Regrets
and apologies. No, Xiphos has not <i>quite</i> been
abandonware, but admittedly it's been close. A couple folks'
activities have driven me out of my darkened hovel.<br>
<br>
At this time, I need some assistance on a couple of things. Much
of the github CI/travis/whatever machinery has always been a
mystery to me, others have handled it before, and I'm feeling
out of touch.<br>
<br>
First, there are 3 open (ancient) PRs and I am trying to
determine whether they're relevant.<br>
<br>
<a class="moz-txt-link-freetext"
href="https://github.com/crosswire/xiphos/pull/1007"
moz-do-not-send="true">https://github.com/crosswire/xiphos/pull/1007</a><br>
updates USE_GTK_3 to use GTK_CHECKVERSION(3,0,0).<br>
Fine idea. Seems incomplete. There are a number of instances of
USE_GTK_3 not covered by the change. I can always merge it, then
do another update referencing it with the remainder, that would
be fine. But comments mention that CI is not functional because
of repo perms to allow the .com name. I don't know where this is
done. Clues for the clueless would be welcome.<br>
<br>
<a class="moz-txt-link-freetext"
href="https://github.com/crosswire/xiphos/pull/1103"
moz-do-not-send="true">https://github.com/crosswire/xiphos/pull/1103</a><br>
adds dbus stanza to src/main/CMakeLists.txt<br>
Seems fine on its face, but comment is that dbus fails on Nix,
yet I've never seen a failure of this anywhere. Needed?
Critical? Ignorable?<br>
<br>
<a class="moz-txt-link-freetext"
href="https://github.com/crosswire/xiphos/pull/972"
moz-do-not-send="true">https://github.com/crosswire/xiphos/pull/972</a><br>
appears to annihilate GTK2 usage entirely. Sorry, so long as we
support Windows build, where we lack adequate GTK3 support (much
less GTK4), we are stuck with #ifdef-preserving GTK2 interfaces.<br>
Am I right about this? Is there better GTK3/4 for Windows?<br>
<br>
Other updates already done:<br>
- Basic copyright update<br>
- Live chat reference update from freenode to libera<br>
- WebKit regression workaround using environment variable, since
WK people are not fixing that problem.<br>
<br>
A main driving reason for all this at this time is that
webkit2gtk-4.0 is about to go defunct in favor of
webkit2gtk-4.1. This will cause trouble as e.g. Fedora 40 and
other distros firm up. So updates were merged recently which
move us away from 4.0 + soup2 to 4.1 + soup3.<br>
<br>
In the CI/travis world, auto-builds are always failing. This
hasn't concerned me much up to now but if I'm going to make a
release, that stuff ought to run. Aaron Rainbolt made a comment
at some point that this is due to a mis-expectation of building
in a git tree which ¿is not the case when CI/travis is
operating?. Again, I need clues for how to address this.<br>
</font> <br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
xiphos-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:xiphos-devel@crosswire.org">xiphos-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://crosswire.org/mailman/listinfo/xiphos-devel">http://crosswire.org/mailman/listinfo/xiphos-devel</a>
</pre>
</blockquote>
the webkit2gtk thing may be an issue. Currently (in Slackware) the
version 4 of the webkit2gtk api (2.42.5) is used by wxGTK3,
wxWidgets, wxPython4, gambas3 as well as xiphos and yelp. as far as
I know all these don't like the 4.1 version of webkit2gtk.<br>
if anyone else has more info I would be interested. I will make more
enquiries myself as well, and report back. If xiphos could support
both versions of the api, perhaps by a build flag to select which
version to use, that would be ideal, as it would cover all bases,
allowing for the migration when it happens, as you can't have both
api versions of webkit2gtk installed on a system at the same time. <br>
I don't know if the api differences would affect what xiphos uses.
If it is just declarations of functions with unused extra
parameters, then conditional declarations would do the trick.<br>
Regards, Tim<br>
<br>
</body>
</html>