From vagus.eques at gmail.com  Tue Apr  5 20:25:25 2022
From: vagus.eques at gmail.com (Daniel Maxson)
Date: Wed, 6 Apr 2022 00:25:25 +0000
Subject: [xiphos-devel] failed github auto-build
In-Reply-To: <CAKULjP4731RT0+8DPK+3gK8HdzDj3N=biseGjVJspf9YDx6cGA@mail.gmail.com>
References: <ddcef9dc-25e0-77df-d2f9-7ae2e667e745@kleinpaste.org>
 <CAKULjP4731RT0+8DPK+3gK8HdzDj3N=biseGjVJspf9YDx6cGA@mail.gmail.com>
Message-ID: <CAKULjP6SxnKiA_RYxgv9hefZOB4tchpH8Pcr85J-exhinQ7aEg@mail.gmail.com>

Well since it's been a while with no reply on this, this evening I went
ahead and made the changes I proposed back in January in my own fork. This
definitely seems to have solved the YAML loader problem you were originally
asking about, but Linux builds are still failing, now for reasons that seem
to just have to do with mismatched distro-specific dependencies. Dunno if
you have an easy way to get these distros and dependencies back into a
state that makes sense or if I need to dig more into manually fixing all
that, though.

Anyway, I made the PR against jtojnar's fork that's the basis for the
original PR you were asking about. My PR is here:
https://github.com/jtojnar/xiphos/pull/1

That fork seems not to have the CI actions enabled, but mine does and you
can see the build logs here:
https://github.com/maxsond/xiphos/actions/runs/2099367438

On Sun, Jan 23, 2022 at 1:54 PM Daniel Maxson <vagus.eques at gmail.com> wrote:

> Hey! Long-time lurker, first-time reply-er. It looks like this is in some
> way related to PyYAML deprecating directly calling load() without a Loader
> because of security concerns (although that was back in 2020 so I'm
> surprised this is only coming up now):
> https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-Deprecation
>
> My proposal would be that rather than curling this build script, a build
> script be brought into the Xiphos project (which for consistency/ease could
> mean simply copying the currently curled script, which is fair game since
> both mate-desktop from which this script is taken and Xiphos are licensed
> under GPLv2) which calls yaml.load with a specific loader. FullLoader is
> the default recommended by PyYAML in the documentation I linked.
>
> Unless (a) someone thinks this is undesirable or (b) wants to do this, I
> wouldn't mind taking a stab at updating the broken PR (though I'd be
> surprised if this doesn't come up in other places since I don't see a
> direct correlation between #1103's changes and this). I would plan to test
> against Ubuntu in WSL which should be good enough to cover what needs
> covering to make sure this builds for non-Windows systems.
>
> On Sun, Jan 23, 2022 at 12:51 PM Karl Kleinpaste <karl at kleinpaste.org>
> wrote:
>
>> Someone offered a simple pull request for a dependency glitch.
>> Failed for everything but Windows builds.
>> Something docker-related, not part of Xiphos source.
>>
>> $ pwd
>> /home/karl/src/bible/xiphos
>> $ find -name dock*
>> $ grep -i load .ci-build.yml
>>         curl -Ls -o gtkhtml-4.10.0.tar.xz
>> https://download.gnome.org/sources/gtkhtml/4.10/gtkhtml-4.10.0.tar.xz
>> $
>>
>> Would anyone care to look?
>> https://github.com/crosswire/xiphos/pull/1103
>>
>> _______________________________________________
>> xiphos-devel mailing list
>> xiphos-devel at crosswire.org
>> http://crosswire.org/mailman/listinfo/xiphos-devel
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://crosswire.org/pipermail/xiphos-devel/attachments/20220406/a7364aae/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rYY3neKrZ7yQ8SpX.png
Type: image/png
Size: 49995 bytes
Desc: not available
URL: <http://crosswire.org/pipermail/xiphos-devel/attachments/20220406/a7364aae/attachment-0001.png>