[xiphos-devel] attempting to clear matters for a release

Tim Dickson dickson.tim at googlemail.com
Fri Feb 16 05:37:39 EST 2024


On 15/02/2024 23:28, Karl Kleinpaste wrote:
> 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.
>
> Yes, I've been gone an indecent amount of time again. Regrets and 
> apologies. No, Xiphos has not /quite/ been abandonware, but admittedly 
> it's been close. A couple folks' activities have driven me out of my 
> darkened hovel.
>
> 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.
>
> First, there are 3 open (ancient) PRs and I am trying to determine 
> whether they're relevant.
>
> https://github.com/crosswire/xiphos/pull/1007
> updates USE_GTK_3 to use GTK_CHECKVERSION(3,0,0).
> 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.
>
> https://github.com/crosswire/xiphos/pull/1103
> adds dbus stanza to src/main/CMakeLists.txt
> 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?
>
> https://github.com/crosswire/xiphos/pull/972
> 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.
> Am I right about this? Is there better GTK3/4 for Windows?
>
> Other updates already done:
> - Basic copyright update
> - Live chat reference update from freenode to libera
> - WebKit regression workaround using environment variable, since WK 
> people are not fixing that problem.
>
> 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.
>
> 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.
>
> _______________________________________________
> xiphos-devel mailing list
> xiphos-devel at crosswire.org
> http://crosswire.org/mailman/listinfo/xiphos-devel
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.
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.
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.
Regards, Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://crosswire.org/pipermail/xiphos-devel/attachments/20240216/ce712146/attachment.htm>


More information about the xiphos-devel mailing list