On 10/1/23 17:02, Peter von Kaehne wrote:
Have you spoken with Karl, have you signed up to Xiphos’ mailing lists?
I don't know how to contact Karl, I figured he'd see stuff here since Fr
mentioned him earlier.
The Xiphos mailing lists are either invisible or shut down. See
https://www.crosswire.org/mailman/listinfo/
Xiphos has had development pauses of years and suddenly spurts , and Karl is as
far as I know still very much around.
I think he would welcome any new input for sure and if (I have not the
foggiest) he wants to pass it on - he handled 15 years ago the transition in
maintainership/lead developership from Terry to himself in the most gracious
possible form. He will handle a new one from him to someone else equally
graceful.
Good to know, thank you!
Aaron
Peter
Sent from my phone. Please forgive misspellings and weird “corrections”
On 1 Oct 2023, at 21:50, Aaron Rainbolt <arraybo...@gmail.com> wrote:
The Xiphos fork has been created! https://github.com/ArrayBolt3/xiphos-ng I'm
about to push a build failure fix to it in a few moments. Feel free to make new
pull requests, bug reports, suggestions, etc. here. Lord willing I'll be
monitoring things and getting additions made.
Currently the fork is named xiphos-ng (ng for Next Generation, since that's a
rather popular naming convention for when you pick up an old project), however
I intend for the program name to remain Xiphos. This is because I don't expect
there to ever be a release of xiphos-ng, but rather hope that it will just be
absorbed into the Xiphos project and then development will resume there. In the
event Xiphos is truly and permanently dead, however, we can come up with a
better name for xiphos-ng and then mass-rename and rebrand everything.
Also, the SWORD fixes in Fedora seem to be coming along (I'm working on getting
the package through initial review currently), so we should be OK on that front
if all goes well.
Aaron
On 10/1/23 03:34, Fr Cyrille wrote:
Le 01/10/2023 à 08:59, Aaron Rainbolt a écrit :
On 9/28/23 13:35, Fr Cyrille wrote:
Le 28/09/2023 à 18:13, Aaron Rainbolt a écrit :
Hey, thanks for your help!
I was able to just repack and remove most everything offending. I figured I
should share the info upstream so that if there was anything you wanted to do
on your end, you could, but obviously if you're comfortable keeping things as
they are, I don't have a problem with that :)
I'll submit a patch for the Python bindings, the fix was fairly simple.
As for ftpparse, I could potentially try writing a replacement myself and license
it as GPLv2. We already probably have a good starting point since the FileZilla
project is under GPL-2.0-or-later, and appears to have its own independently
developed directory litsing parser written in C++ (see
https://svn.filezilla-project.org/filezilla/FileZilla3/trunk/src/engine/directorylistingparser.cpp?revision=10945&view=markup).
We could port the logic from that into something SWORD-compatible perhaps?
One more question about the CMake files, you mention that FindXZ.cmake is your original
contribution and would be GPLv2, but it appears to be ported from the BSD-3-Clause FindBZIP2.cmake.
Just to be clear, since it contains your modifications, it should be "upgraded" to GPLv2
as it now contains your GPLv2 contributions? If so, are there any other files in the CMake folder
that should be similarly "upgraded"? Potentially all of them if they've all had to be
modified for SWORD?
Thanks so much for your help! Also, did you also previously maintain Xiphos and
Bibletime? If so, I would love to take maintainership of those too so I can
keep everything SWORD-related from dropping out of Fedora.
Dear Aaron,
What a magnificent proposal this is!! I have been lamenting to the Lord for
months, seeing Xiphos stagnate... and risking disappearing. Personally I am
under Ubuntu.
At the beginning of the year I asked the Lord in my prayer to give us
developers for Xiphos, you could be the answer to this prayer. If Karl could
react to your proposal that would be great.
I will follow this proposal with great interest.
I actually know C and C++, so I might be able to help there. If I have some
spare time and am itching to code, I'll fiddle with it and see if I can
implement requested features and fix bugs.
Also I used to be an Ubuntu Developer, and intend on returning to Ubuntu
development once work starts on 24.04 LTS. So I may end up being able to help
accelerate the acceptance of updated SWORD-related software into Debian,
Ubuntu, and Fedora if, Lord willing, all goes well.
Thanks for the encouragement!
You made my day! God be praised... I will help to with testing, ideas (many),
compiling... May God send still 2 or 3 dev for it.
Aaron
God bless, and thanks again.
Aaron
On 9/28/23 07:05, Greg Hellings wrote:
Aaron,
As the previous maintainer who dropped support, thank you for picking it up. I
have moved on from being a Fedora user (NixOS these days) and was no longer
maintaining those packages nor the apps that depend on it. I am, however, the
pumpkin holder for the Python and Perl bindings. If you want to submit a patch
to us that gets those working again I would be happy to include it upstream.
Any files under the cmake folder were contributed by me. Those noting a license
were taken from later CMake versions and would match licenses there. The FindXZ
file is my original contribution and is under the GPLv2 like all other original
SWORD code.
The gSOAP and Objective-C bindings should be safe to remove in Fedora as there
is no need for them there.
The win32 files would only affect the MinGW build of sword in Fedora, which was
not retired as it was unaffected by the Python changes.
ftpparse is a constant thorn in our side whenever people become hung up on the
commercial clause. While not strictly necessary to SWORD, as HTTP and HTTPS are
supported if the library is built with cURL support, it would be a huge loss of
functionality for most users. It probably is time to consider rewriting their
functionality.
The Android jar file is also unnecessary for your packaging and you can safely
delete it. And the whole pqa folder for diatheke should be tossed. Likely at
the SVN level, as I'm sure we are not building Palm binaries anymore.
Hope that helps.
--Greg
On Thu, Sep 28, 2023, 01:06 Aaron Rainbolt <arraybo...@gmail.com> wrote:
Good morning/evening, and thanks for your time.
Recently SWORD was removed from Fedora 39 because of a bug
relating to
the python bindings (it's still using distutils rather than
setuptools,
which needed to be fixed, but the maintainer didn't fix it in
time). I'm
attempting to get SWORD back into Fedora by fixing the issue, but
as the
package was already retired, I'm preparing to reintroduce it as if it
were being added for the first time. For the sake of making things go
smoothly, I did a full licensing audit on the SWORD source code to
ensure that all licenses were compliant with Fedora's requirements.
Some of the results of this audit were less-than-ideal, so I
thought I
would share the results with you so that you can take any measures
you
deem appropriate. I'm in the process of resolving these issues in
Fedora.
* There are several files under sword-1.9.0/cmake that have unclear
licenses (referring to "the BSD license" but without specifying which
version, and telling the user to look at a file that doesn't exist
for
the license details). I *believe* these files are licensed under
BSD-3-Clause, as I found the original source for all but one of them,
however I could not find the original source for
sword-1.9.0/cmake/FindXZ.cmake.
* The gSOAP bindings contain a file,
sword-1.9.0/bindings/gsoap/include/stdsoap.h, which has no license
and
an "All rights reserved" notice.
* The Objective-C bindings have a similar problem - the following
files
under sword-1.9.0/bindings/objc all have no license and an "All
rights
reserved" notice:
- ObjCSword.h
- src/Notifications.h (yes I realize this file consists
entirely of
comments but this is still worrying)
- src/SwordBibleBook.h
- src/SwordBibleBook.m
- src/SwordBibleChapter.h
- src/SwordBibleChapter.m
- src/SwordBibleTextEntry.h
- src/SwordBibleTextEntry.m
- src/SwordInstallSource.h
- src/SwordInstallManager.h
- src/SwordInstallManager.mm
- src/SwordInstallSource.mm
- src/SwordKey.h
- src/SwordKey.m
- src/SwordListKey.h
- src/SwordListKey.mm
- src/SwordLocaleManager.h
- src/SwordLocaleManager.mm
- src/SwordModuleIndex.h
- src/SwordModuleIndex.m
- src/SwordModuleTextEntry.h
- src/SwordModuleTextEntry.m
- src/SwordTreeEntry.h
- src/SwordTreeEntry.m
- src/SwordVerseKey.h
- src/SwordVerseKey.mm
- src/SwordVerseManager.h
- src/SwordVerseManager.m
- src/VerseEnumerator.h
- src/VerseEnumerator.m
- src/services/Configuration.h
- src/services/Configuration.m
- src/services/iOSConfiguration.h
- src/services/iOSConfiguration.m
- src/services/OSXConfiguration.h
- src/services/OSXConfiguration.m
- SWORD/SWORD/SWORD.h
- SWORD/SWORD/SWORD.m
- test/SwordListKeyTest.h
- test/SwordListKeyTest.m
- test/SwordModuleLongRunTest.h
- test/SwordModuleLongRunTest.mm
- test/SwordModuleTest.h
- test/SwordModuleTest.m
* Two files under sword-1.9.0/src/utilfuns/win32 are under non-free
licenses - they prohibit the sale of media containing those files for
anything greater than the cost of distribution.
* The files sword-1.9.0/include/ftpparse.h and
sword-1.9.0/src/utilfuns/ftpparse.c are under informal non-free
licenses
prohibiting commercial use unless the copyright owner is informed of
what program uses the files. This code appears to be critical to
SWORD's
functionality (as FTP is used for module downloading), so I have
attempted to contact the author and ask that ftpparse be
relicensed to
0BSD (which should be compatible with the licenses in SWORD).
In addition to the above, I discovered some pre-built binary files
floating around:
-
sword-1.9.0/bindings/Android/SWORD/gradle/wrapper/gradle-wrapper.jar
- sword-1.9.0/utilities/diatheke/pqa/Diatheke.pqa
While these aren't strictly a problem, they do have to be removed in
Fedora. You might consider removing them from your SVN repo if
possible
and not too inconvenient.
I hope this message finds you all doing well! God bless, and
thanks for
all the work you've put into the SWORD Project!
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
