Re: [sword-devel] Packaging Ezra Bible App for Snap and Flatpak users?
On Sat, Jan 20, 2024 at 4:27 PM Matěj Cepl wrote: > > On Sat Jan 20, 2024 at 7:18 PM CET, Aaron Rainbolt wrote: > > It appears that the Ezra Bible App can only be installed using > > upstream packages for a select group of popular Linux distributions > > currently. It would be handy for users to be able to install it by > > using widely available repositories such as the Snap Store and > > Flathub. I'm fairly skilled at software packaging for distros (though > > I haven't done Snap or Flatpak before - I'm interested in learning how > > though) and am thinking about trying to make Snap and Flatpak packages > > for Ezra Bible App. > > Given that Snap really works only on Ubuntu (AFAIK, certainly it > does work neither with Fedora nor with openSUSE), then I would > hugely prefer Flatpak. No clue about openSUSE, but I know Snap works on Debian and I thought for sure it worked on Fedora (though of course you'd have to install snapd first, whereas it's preinstalled on Ubuntu). But still, I do intend on doing both Snap and Flatpak - each has a user base that the other one doesn't. I'll go ahead and do the Flatpak first since I now know someone wants a Flatpak for it :) Thanks for letting me know, and God bless. > Best, > > Matěj > > -- > http://matej.ceplovi.cz/blog/, @mcepl@floss.social > GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 > > All men's miseries derive from not being able to sit in a quiet > room alone. > -- Blaise Pascal > > ___ > 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] Fwd: Packaging Ezra Bible App for Snap and Flatpak users?
Gah, once again I have failed to send my response to everyone. -- Forwarded message - From: Aaron Rainbolt Date: Sat, Jan 20, 2024 at 1:07 PM Subject: Re: [sword-devel] Packaging Ezra Bible App for Snap and Flatpak users? To: Fr Cyrille On Sat, Jan 20, 2024 at 12:42 PM Fr Cyrille wrote: > > > > Le 20/01/2024 à 19:18, Aaron Rainbolt a écrit : > > It appears that the Ezra Bible App can only be installed using > upstream packages for a select group of popular Linux distributions > currently. It would be handy for users to be able to install it by > using widely available repositories such as the Snap Store and > Flathub. I'm fairly skilled at software packaging for distros (though > I haven't done Snap or Flatpak before - I'm interested in learning how > though) and am thinking about trying to make Snap and Flatpak packages > for Ezra Bible App. > > Adding it to debian repo would be nice too. And easier for sharing modules > than snap. Getting it into Debian would be nice, and I actually thought about doing that initially, but it would be... difficult. Ezra Bible App is Electron-based. Due to the policies of Debian, Ubuntu, Fedora, and probably most other distros I would guess, all of a package's dependencies *have* to be in the distribution's repos in order for software that uses those dependencies to be accepted into the repos. Electron isn't packaged for Debian, Ubuntu, or Fedora. That means in order to get an official Debian package for Ezra, I would have to package **all of Electron.** Electron is based on Chromium, which takes time and eternity to compile even on hardware much faster than anything I own, so actually doing that packaging would be hard, and then on top of it there are potential hurdles with versions and whatnot - for instance Electron upstream is at version 28.1.4, Ezra is still using 17.1.0. Ezra's developers can distribute packages with Ezra and Electron included because they're able to ignore policies like this - their builders can have Internet access at build time, can use software directly from upstream, can take advantage of package managers such as npm, etc. None of those are available in an official Debian package - the package has to be able to build without Internet access, use only distro-internal dependencies, etc. So... yeah, it would be a **lot** of work. And then I would be the maintainer of Electron in Debian, which is probably a monumental task, one I almost certainly don't have time for. On the other hand, I know there are Electron apps packaged as Flatpaks and Snaps (namely Element, but also others). If I understand correctly, Snap and Flatpak packages have significantly more lenient requirements, which makes packaging much easier for those platforms. Then there would be Ezra packages not only for Debian, Fedora, and derivatives, but also for Arch, Gentoo, RHEL, NixOS, etc., etc. That seems like it would take significantly less time to do and would potentially have a better impact. > Does this seem like a good idea? Are there hurdles I should be aware > of (other than having to work with Electron)? Would the developers > prefer that I not do this? > ___ > sword-devel mailing list: sword-devel@crosswire.org > http://crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page > > > -- > Vous aimez la Bible ? Vous êtes étudiant en théologie ? Utilisez > l'application libre Xiphos ou Andbible et accédez aux textes sources, à des > commentaires, des dictionnaires et beaucoup d'autres fonctionnalités... Me > contacter pour des traductions en français. ___ 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] Packaging Ezra Bible App for Snap and Flatpak users?
It appears that the Ezra Bible App can only be installed using upstream packages for a select group of popular Linux distributions currently. It would be handy for users to be able to install it by using widely available repositories such as the Snap Store and Flathub. I'm fairly skilled at software packaging for distros (though I haven't done Snap or Flatpak before - I'm interested in learning how though) and am thinking about trying to make Snap and Flatpak packages for Ezra Bible App. Does this seem like a good idea? Are there hurdles I should be aware of (other than having to work with Electron)? Would the developers prefer that I not do this? ___ sword-devel mailing list: sword-devel@crosswire.org http://crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] What markup format is SWORD's internal markup, and/or where is it documented?
I think I'm beginning to understand - there is no one internal markup format, but rather there's the binary format, and then the SWORD engine converts that (sorta) into something very similar to the original markup language. Is that about right? I think the markup format I'm seeing then is a subset of OSIS, and probably other modules will have a different syntax. Which would explain why the best way to do this is via filters since I'll need to handle three or so different markup formats depending on what each module uses. In that instance, I guess my question becomes, what markup formats does SWORD support emitting a subset of? OSIS is clearly one, and it sounds like ThML is another. Is there a list of these so I can write the needed Markdown filter for each one? I may attempt to get the Markdown filter collection (if I manage to write it) contributed back to SWORD if that's something the devs are interested in. I'm not used to normal C++, but I can work my way through Qt C++ with little difficulty, so I should hopefully be able to adapt to Qt-less C++ without too many issues. Thanks for your help! On Fri, Dec 15, 2023 at 9:45 PM Troy A. Griffitts wrote: > > Hi Aaron, > > The SWORD engine tries to preserve the best it can the markup from an > imported text for few supported markup formats. The markup used by a SWORD > module is specified in its .conf file. Most new SWORD modules from our > Modules Team are in OSIS markup. If you want to add markdown as a new output > format for SWORD, that would be great. To do this, you would want to follow > the pattern you see for one of out existing output formats. I would suggest > XHTML. E.g., copy the 3 or so *XHTML filters you see here and modify the > output from XHTML to markdown. > > https://crosswire.org/svn/sword/trunk/src/modules/filters/ > > Hope this gets you started. Let me know if you have questions, > > Troy > > > On December 15, 2023 20:26:22 MST, Aaron Rainbolt > wrote: >> >> I didn't mean the actual compiled files - I meant the kind of markup you end >> up with if you use swModule->getRawEntry(). It's the same kind of markup you >> see if you use mod2imp on a module. So far the modules I've used this on >> seem to have some sort of pattern to them (there's tags with "lemma" and >> "morph" attributes for Strong's numbers and morphology, tags for... >> something, looks like it's part of how red-letter Bibles work because of the >> "who" attribute, and things like that). I assume it's this markup that is >> parsed by the existing filters, and that I would need to parse were I to >> write my own filter. >> >> My text renderer does indeed support HTML, but it's ability to output >> Markdown is sorely lacking (I *can* tell it to give me whatever's in my text >> editor widget in Markdown format, but it loses information that Markdown is >> perfectly capable of containing). I need to be able to convert between >> Markdown and rich text both ways. On top of all of that I'm trying to >> support a particular flavor of Markdown that isn't normal (the variant >> Reddit uses in particular), so I have to do the parsing myself to implement >> things like superscripts and strikethroughs. Implementing a filter sounds >> like a good idea, but I think I'll have to parse this "internal markup >> format" to do so. >> >> On 12/15/23 21:12, Greg Hellings wrote: >> >> The actual files are a custom binary format which is not documented and is >> not intended to be any sort of standard accessed by anything other than the >> library itself. >> >> Most newer works are imported from an OSIS file. Some older ones were >> imported from GBF (I think?) or ThML (which is basically some basic HTML >> display components mixed with a few tags for identifying things like words >> of Christ or divine names). However, once they are imported as modules some >> of that structure is lost to the proprietary binary format of the SWORD >> module files. >> >> If you want the text in Markdown the best way is to create a filter like the >> existing filters in the engine which can be used to generate HTML, LaTeX, >> etc and write some which produce Markdown output. >> >> Although, since Markdown is basically simplified HTML that is specifically >> intended to make HTML easier to write, why wouldn't you just render out HTML >> from the existing filters and drop that into your Markdown editor? Every md >> editor and renderer I've used will pass HTML through unchanged, allowing the >> author to use its full syntax when they wanted to. >> >> On Fri, Dec 15, 2
Re: [sword-devel] What markup format is SWORD's internal markup, and/or where is it documented?
I didn't mean the actual compiled files - I meant the kind of markup you end up with if you use swModule->getRawEntry(). It's the same kind of markup you see if you use mod2imp on a module. So far the modules I've used this on seem to have some sort of pattern to them (there's tags with "lemma" and "morph" attributes for Strong's numbers and morphology, tags for... something, looks like it's part of how red-letter Bibles work because of the "who" attribute, and things like that). I assume it's this markup that is parsed by the existing filters, and that I would need to parse were I to write my own filter. My text renderer does indeed support HTML, but it's ability to output Markdown is sorely lacking (I *can* tell it to give me whatever's in my text editor widget in Markdown format, but it loses information that Markdown is perfectly capable of containing). I need to be able to convert between Markdown and rich text both ways. On top of all of that I'm trying to support a particular flavor of Markdown that isn't normal (the variant Reddit uses in particular), so I have to do the parsing myself to implement things like superscripts and strikethroughs. Implementing a filter sounds like a good idea, but I think I'll have to parse this "internal markup format" to do so. On 12/15/23 21:12, Greg Hellings wrote: The actual files are a custom binary format which is not documented and is not intended to be any sort of standard accessed by anything other than the library itself. Most newer works are imported from an OSIS file. Some older ones were imported from GBF (I think?) or ThML (which is basically some basic HTML display components mixed with a few tags for identifying things like words of Christ or divine names). However, once they are imported as modules some of that structure is lost to the proprietary binary format of the SWORD module files. If you want the text in Markdown the best way is to create a filter like the existing filters in the engine which can be used to generate HTML, LaTeX, etc and write some which produce Markdown output. Although, since Markdown is basically simplified HTML that is specifically intended to make HTML easier to write, why wouldn't you just render out HTML from the existing filters and drop that into your Markdown editor? Every md editor and renderer I've used will pass HTML through unchanged, allowing the author to use its full syntax when they wanted to. On Fri, Dec 15, 2023, 21:04 Aaron Rainbolt wrote: I had an idea of making a primarily Markdown-centric SWORD frontend that would help with writing Bible studies and whatnot for Markdown-based platforms like Reddit or Obsidian notes. For this purpose, I want to parse the internal markup used by SWORD in its modules, and then use my own custom code to generate Markdown from that. Obviously I can learn a lot about this markup by simply looking at modules that use it, but I do wonder, is this markup at all standardized? Is it documented anywhere? Does it have a name of some sort that I can use to find handlers and tools for it in the SWORD API docs? Thanks, Aaron ___ 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] What markup format is SWORD's internal markup, and/or where is it documented?
I had an idea of making a primarily Markdown-centric SWORD frontend that would help with writing Bible studies and whatnot for Markdown-based platforms like Reddit or Obsidian notes. For this purpose, I want to parse the internal markup used by SWORD in its modules, and then use my own custom code to generate Markdown from that. Obviously I can learn a lot about this markup by simply looking at modules that use it, but I do wonder, is this markup at all standardized? Is it documented anywhere? Does it have a name of some sort that I can use to find handlers and tools for it in the SWORD API docs? Thanks, Aaron ___ 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] SpaRV1909 - some verses seem to have moved between chapters on accident?
See Numbers 12 and 13 - in the AKJV, Numbers 12 is 16 verses long, whereas in SpaRV1909, it's only 15 verses long. Numbers 12:16, mentioning Hazeroth, seems to have accidentally become Numbers 13:1 in SpaRV1909. Then Numbers 13:33 in SpaRV1909 contains the contents of verses 32 and 33 in the AKJV. These kinds of errors don't always occur in exactly this way, but they all seem to involve verses "migrating" into other verses and/or chapters. They're rather widespread throughout the SpaRV1909 module (Numbers 29-30, 1 Samuel 23-24, 2 Samuel 20-21, 2 Chronicles 33-34, Job 35-36, Job 38-40 (this one is particularly weird since both chapters 38 and 40 ended up short and 39 has a LOT of bloat), Hosea 11-12, Jonah 1-2, Acts 19-20, 2 Corinthians 13 (maybe effecting Galatians 1 too?)). This isn't guaranteed to be an exhaustive list, it's just all the spots that made my attempt at converting the module to LaTeX go wonky. Any clue what happened here? I'm happy to try and help debug this further if that would be helpful. ___ sword-devel mailing list: sword-devel@crosswire.org http://crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Where is the source code for individual SWORD modules?
On 10/21/23 02:20, Timothy Allen wrote: On 21/10/23 16:48, Aaron Rainbolt wrote: mod2imp claims to be able to generate LaTeX (something like `mod2imp -r LATEX AKJV`) but at least the Ubuntu build of libsword-utils mod2imp is broken in this regard - any time I try to use any of the filters, it tells me "mod2imp: Unknown argument: LATEX" or something similar for every single possible output format (OSIS, XHTML, RTF, etc.). That's because it doesn't use a flexible argument parser like getopt or similar. When the help text says: usage: mod2imp [options] ...it really means it, the options have to go *after* the module name, not before: mod2imp -r LATEX AKJV # fails with "Unknown argument" mod2imp AKJV -r LATEX # succeeds Oh. That explains a lot :P My brain is so used to tools expecting the last argument to be the source file that I read the "" and "[options]" part backwards and thought it expected the module name at the end. So... lesson learned, thank you for catching my silly mistake. ...although in this case, the IMP markup and the LaTeX markup get a bit mixed and it's not the easiest to work with. You may have better luck with the example command-line SWORD tool, diatheke: diatheke -b AKJV -f LATEX -k Genesis I ended up writing a small tool in C# that parsed the IMP markup and spit out incomplete LaTeX code. I used Mono to run the tool under Linux, then took the output and pasted it into a "skeleton" document I had written earlier. (The IMP markup for the AKJV module was really simple thanks to the simplicity of the module itself so it ended up being pretty easy.) If anyone's interested in the end result I got, I'm happy to share it. I think it came out pretty good. Aaron Timothy ___ 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
Re: [sword-devel] Where is the source code for individual SWORD modules?
On Sat, Oct 21, 2023 at 12:20 AM Greg Hellings wrote: In general the imported file will not be available since it is not the source of those modules. Other than for the KJV itself, Crosswire is not the authoritative source of the texts. Often any OSIS file is a product of a conversation from the original source. If anything has been kept it should be a script to produce that OSIS file so that, if the source material is updated, the module can be automatically created from it. Very old modules which have not been updated in a decade+ might not have any reproducible material floating around at all if they predate that process. Well, right, I get that, but when the text I want to get at is in the form of a SWORD module, I don't need the authoritative source, I just need something I can parse and turn into what I want. Which it turns out mod2imp will give me, so I guess I don't need the OSIS / TEI / ThML sources after all. I just expected that Crosswire probably had them somewhere since https://wiki.crosswire.org/DevTools:Modules mentioned that Crosswire only accepted module source code when submitting a module, not a pre-built module. The KJV(A) module pair are the exception to this and should be located on the server somewhere. As for generating LaTeX, I thought the engine could already do that? I thought Peter had added a filter for that back when he was doing some work with the texts. You should be able to iterate module and generate the text from there, if a render filter exists for LaTeX. If not, now would be a great time for you to learn the filter API (it is akin to an XML SAX style of interface) and write one! mod2imp claims to be able to generate LaTeX (something like `mod2imp -r LATEX AKJV`) but at least the Ubuntu build of libsword-utils mod2imp is broken in this regard - any time I try to use any of the filters, it tells me "mod2imp: Unknown argument: LATEX" or something similar for every single possible output format (OSIS, XHTML, RTF, etc.). I should try to build SWORD from source and see if that behaves any better. I don't know what XML SAX even is but it sounds difficult and scary :P Might be fun to look into if I get the time though. Thanks for your help! Aaron --Greg On Fri, Oct 20, 2023, 23:28 Aaron Rainbolt wrote: Gah, I am forgetful. I can just use mod2imp to get parsable text. It's not exactly what I was looking for but it'll work good enough :D On 10/20/23 23:15, Aaron Rainbolt wrote: > I don't know if I'm just blind or if these aren't public, but I cannot > find the OSIS (or whatever format) code for individual SWORD modules > in the Crosswire repository. Specifically I'm trying to find the > source for the AKJV module. I'd like to take the code and parse it > myself for a project of my own (I'm trying to typeset the AKJV > translation using LaTeX, and may want to do the same sort of thing > with other modules). As it is, I'm having to open the modules in > Xiphos, and then copy and paste their text one chapter at a time into > my formatting tools, which is... cumbersome. If I could get the source > code for the modules, I could just write a parser that would do the > whole job for me in one go. > > Are the OSIS sources kept private intentionally? If not, where would I > find them to download them? > > (Note that I understand why some modules' source code might be > private, for things like the NASB module. But it would be nice if the > code for public domain or otherwise permissively licensed modules were > available for public download.) > ___ 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
Re: [sword-devel] Where is the source code for individual SWORD modules?
Gah, I am forgetful. I can just use mod2imp to get parsable text. It's not exactly what I was looking for but it'll work good enough :D On 10/20/23 23:15, Aaron Rainbolt wrote: I don't know if I'm just blind or if these aren't public, but I cannot find the OSIS (or whatever format) code for individual SWORD modules in the Crosswire repository. Specifically I'm trying to find the source for the AKJV module. I'd like to take the code and parse it myself for a project of my own (I'm trying to typeset the AKJV translation using LaTeX, and may want to do the same sort of thing with other modules). As it is, I'm having to open the modules in Xiphos, and then copy and paste their text one chapter at a time into my formatting tools, which is... cumbersome. If I could get the source code for the modules, I could just write a parser that would do the whole job for me in one go. Are the OSIS sources kept private intentionally? If not, where would I find them to download them? (Note that I understand why some modules' source code might be private, for things like the NASB module. But it would be nice if the code for public domain or otherwise permissively licensed modules were available for public download.) ___ 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] Where is the source code for individual SWORD modules?
I don't know if I'm just blind or if these aren't public, but I cannot find the OSIS (or whatever format) code for individual SWORD modules in the Crosswire repository. Specifically I'm trying to find the source for the AKJV module. I'd like to take the code and parse it myself for a project of my own (I'm trying to typeset the AKJV translation using LaTeX, and may want to do the same sort of thing with other modules). As it is, I'm having to open the modules in Xiphos, and then copy and paste their text one chapter at a time into my formatting tools, which is... cumbersome. If I could get the source code for the modules, I could just write a parser that would do the whole job for me in one go. Are the OSIS sources kept private intentionally? If not, where would I find them to download them? (Note that I understand why some modules' source code might be private, for things like the NASB module. But it would be nice if the code for public domain or otherwise permissively licensed modules were available for public download.) ___ sword-devel mailing list: sword-devel@crosswire.org http://crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream
I believe I do understand, and think that we have a good plan. Some users can't or don't want to use distro packages and want newer software, so your upstream repo would be helpful for them. Other users can't or don't want to use upstream third-party repos and want distro version upgrades to be more likely to work, and so the distro packages (which you would not be expected to help maintain) would be helpful for them. I don't see any reason why we shouldn't have both. If you'd like, I might even be able to help with packaging for the upstream repos. (If it's any consolation, users will oftentimes go and get upstream packages and then come to distro package maintainers for help, so I get the frustration of users seeking support from the wrong places :P) Aaron On 10/6/23 03:12, Jaak Ristioja wrote: Please understand, that we might nevertheless decide to host our own Fedora repository for BibleTime as well. BibleTime developers are not responsible for packages we did not create ourselves, but when issues with these packages arise many users still complain directly to us. Oftentimes they just ask for some newer version of BibleTime to be packaged for their platform. Many distributions also have restrictive packaging policies which prevent introducing new (major) versions of packages to stable distribution versions. Hosting our own repositories might help in that regard and we would also not be tied to having to support older versions of BibleTime we no longer can or wish to support. We have very limited resources and can't afford to manage BibleTime within distribution repositories. On 06.10.23 09:58, Aaron Rainbolt wrote: No worries there, I would be doing all the work of managing BibleTime within the Fedora repositories, the devs wouldn't have to do extra work for that to happen. If the BibleTime developers are interested in hosting their own repos for other distros, that's certainly their option (and a good idea in my opinion), however having BibleTime directly in distribution repos will obviously make it easier for end-users to install and use it, so I'd like to make that happen by maintaining the package in Fedora. (I also have experience with Debian packaging so if the current Debian maintainer gives up on it, I might be able to help there too.) On Fri, Oct 6, 2023 at 1:42 AM Jaak Ristioja wrote: Hi, On 05.10.23 20:59, Aaron Rainbolt wrote: Thanks! If all of the comaintainers for Xiphos and BibleTime are also no longer available or interested, I think it would be helpful if you could go into https://src.fedoraproject.org/rpms/xiphos and https://src.fedoraproject.org/rpms/bibletime and click the "Orphan" button on those. I'll take them once that's done and should be able to help keep them maintained. BibleTime would be interested in hosting their own package repositories for different distributions and their versions, which would be updated by the CI (see [1]) and perhaps be of low maintenance burden. We don't have the resources to commit to managing BibleTime packages under the umbrella of different distros. Best regards, J [1]: https://github.com/bibletime/bibletime/issues/258 ___ 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
Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream
No worries there, I would be doing all the work of managing BibleTime within the Fedora repositories, the devs wouldn't have to do extra work for that to happen. If the BibleTime developers are interested in hosting their own repos for other distros, that's certainly their option (and a good idea in my opinion), however having BibleTime directly in distribution repos will obviously make it easier for end-users to install and use it, so I'd like to make that happen by maintaining the package in Fedora. (I also have experience with Debian packaging so if the current Debian maintainer gives up on it, I might be able to help there too.) On Fri, Oct 6, 2023 at 1:42 AM Jaak Ristioja wrote: > > Hi, > > On 05.10.23 20:59, Aaron Rainbolt wrote: > > Thanks! If all of the comaintainers for Xiphos and BibleTime are also no > > longer available or interested, I think it would be helpful if you could > > go into https://src.fedoraproject.org/rpms/xiphos and > > https://src.fedoraproject.org/rpms/bibletime and click the "Orphan" > > button on those. I'll take them once that's done and should be able to > > help keep them maintained. > > BibleTime would be interested in hosting their own package repositories > for different distributions and their versions, which would be updated > by the CI (see [1]) and perhaps be of low maintenance burden. We don't > have the resources to commit to managing BibleTime packages under the > umbrella of different distros. > > Best regards, > J > > > [1]: https://github.com/bibletime/bibletime/issues/258 > ___ > 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
Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream
On 10/5/23 13:06, Greg Hellings wrote: I've gone ahead and directly added you as an admin on the two projects. Thank you so much! On Thu, Oct 5, 2023 at 1:00 PM Aaron Rainbolt wrote: On 9/28/23 11:29, Greg Hellings wrote: > > > On Thu, Sep 28, 2023, 12:14 Aaron Rainbolt wrote: > > 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 :) > > > There are others who are pumpkin holders for separate parts and > they'll need to decide on updating their pieces. I own CMake and the > Swig bindings (Python and Perl for us). > > > 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=markup <https://svn.filezilla-project.org/filezilla/FileZilla3/trunk/src/engine/directorylistingparser.cpp?revision=10945=markup> > <https://svn.filezilla-project.org/filezilla/FileZilla3/trunk/src/engine/directorylistingparser.cpp?revision=10945=markup <https://svn.filezilla-project.org/filezilla/FileZilla3/trunk/src/engine/directorylistingparser.cpp?revision=10945=markup>>). > > We could port the logic from that into something SWORD-compatible > perhaps? > > > That would probably work. Part of the goal with SWORD is that it needs > no hard external library dependencies. Thus why ftpparse has been > included inline. A novel contribution that replaces those but is still > highly portable C would likely be welcomed. > > > 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? > > > I don't believe I had to modify anything. They were simply pulled in > so I could maintain support for old versions of CMake - like on CentOS > 6 and old Ubuntu LTS versions at the time - that had the core > functionality needed but just lacked a file which newer CMake had > bundled. Including most of them is likely a moot point by now as those > versions are ancient. Yes, I undoubtedly modified it from FindBZIP2 as > it was a later addition to the optional dependencies. The only reason > to upgrade to GPL2 is that it's the exclusive license and version for > SWORD contributions, in absence of compelling reasons to the contrary. > > > 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. > > > I'm fairly certain that I am. If not the owner I was the defacto > maintainer. You are welcome to take over those packages, for sure. Let > me know if you need me to do the needful for that. I don't think > they've been officially orphaned for F39, but would be on the chopping > block for F40 in the absence of sword making it back in. Thanks! If all of the comaintainers for Xiphos and BibleTime are also no longer available or interested, I think it would be helpful if you could go into https://src.fedoraproject.org/rpms/xiphos and https://src.fedoraproject.org/rpms/bibletime and click the "Orphan" button on those. I'll take them once that's done and should be able to help keep them m
Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream
On 9/28/23 11:29, Greg Hellings wrote: On Thu, Sep 28, 2023, 12:14 Aaron Rainbolt wrote: 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 :) There are others who are pumpkin holders for separate parts and they'll need to decide on updating their pieces. I own CMake and the Swig bindings (Python and Perl for us). 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=markup <https://svn.filezilla-project.org/filezilla/FileZilla3/trunk/src/engine/directorylistingparser.cpp?revision=10945=markup>). We could port the logic from that into something SWORD-compatible perhaps? That would probably work. Part of the goal with SWORD is that it needs no hard external library dependencies. Thus why ftpparse has been included inline. A novel contribution that replaces those but is still highly portable C would likely be welcomed. 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? I don't believe I had to modify anything. They were simply pulled in so I could maintain support for old versions of CMake - like on CentOS 6 and old Ubuntu LTS versions at the time - that had the core functionality needed but just lacked a file which newer CMake had bundled. Including most of them is likely a moot point by now as those versions are ancient. Yes, I undoubtedly modified it from FindBZIP2 as it was a later addition to the optional dependencies. The only reason to upgrade to GPL2 is that it's the exclusive license and version for SWORD contributions, in absence of compelling reasons to the contrary. 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. I'm fairly certain that I am. If not the owner I was the defacto maintainer. You are welcome to take over those packages, for sure. Let me know if you need me to do the needful for that. I don't think they've been officially orphaned for F39, but would be on the chopping block for F40 in the absence of sword making it back in. Thanks! If all of the comaintainers for Xiphos and BibleTime are also no longer available or interested, I think it would be helpful if you could go into https://src.fedoraproject.org/rpms/xiphos and https://src.fedoraproject.org/rpms/bibletime and click the "Orphan" button on those. I'll take them once that's done and should be able to help keep them maintained. Thanks for all your help, and God bless! Aaron --Greg 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.
[sword-devel] [PATCH] Migrate Python bindings installation script from distutils to setuptools, attempt 2
Apologies for my initial failed attempt, I made a number of blunders in
my first patch.
This second patch:
* Only modifies the CMake build system (the previous changes to
Autotools was the result of me patching more than was necessary)
* Uses correct indentation (I had spaces and tabs confused before, now
I'm using tabs correctly)
* Successfully applies against the head of SVN and against the 1.9.0 tarball
* Successfully builds against the 1.9.0 tarball (I haven't tried
building SVN with this yet)
* Switches the Python setup script embedded in the CMake system from
using distutils to using setuptools
* Adds a SWORD_PYTHON_INSTALL_ROOT build option for allowing the Python
bindings to be installed without building a Python egg (works around
https://github.com/pypa/setuptools/issues/3143)
* Has the patch as an attachment since it appears either GMail or
Thunderbird potentially mangled my patch last time
As before, everything in the patch is made available under GPLv2.
--- a/bindings/swig/python/CMakeLists.txt 2023-10-02 20:55:56.264801835 -0500
+++ b/bindings/swig/python/CMakeLists.txt 2023-10-02 20:59:53.103289769 -0500
@@ -25,7 +25,7 @@
SET(PY_SCRIPT "#!${PYTHON_EXECUTABLE}
-from distutils.core import setup, Extension
+from setuptools import setup, Extension
setup(
name='sword',
version='${SWORD_VERSION}',
@@ -51,8 +51,11 @@
WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
# Allow user installation to custom directory
+IF(NOT SWORD_PYTHON_INSTALL_ROOT STREQUAL "")
+ SET(SETUP_ARGS "\"--root=${SWORD_PYTHON_INSTALL_ROOT}\"")
+ENDIF(NOT SWORD_PYTHON_INSTALL_ROOT STREQUAL "")
IF(NOT SWORD_PYTHON_INSTALL_DIR STREQUAL "")
- SET(SETUP_ARGS "\"--prefix=${SWORD_PYTHON_INSTALL_DIR}\"")
+ SET(SETUP_ARGS "${SETUP_ARGS}\"--prefix=${SWORD_PYTHON_INSTALL_DIR}\"")
ENDIF(NOT SWORD_PYTHON_INSTALL_DIR STREQUAL "")
CONFIGURE_FILE("${CMAKE_CURRENT_SOURCE_DIR}/install.cmake.in"
"${CMAKE_CURRENT_BINARY_DIR}/install.cmake")
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] [PATCH] Migrate setup.py files from using distutils to using setuptools
Actually, I realize now that I also am patching a CMake file with the distutils -> setuptools transition. That's probably all that's needed (though I patched everywhere I saw distutils for good measure and it built). I'll resubmit and patch only just the CMake file. On 10/2/23 20:38, Aaron Rainbolt wrote: I realize these are autotools files, but they are somehow getting pulled into the CMake build process. The spec file for the Fedora build is still using CMake, the build was failing because of an attempt to use distutils rather than setuptools, and the only places where distutils was mentioned was in Python scripts embedded into the Autotools files. Patching them fixed the problem, so I assume the CMake builds must be using those files to generate the Python scripts for installing the Python bindings. I realize now that my patch was against the 1.9.0 tarball, not against the latest SVN revision (why I didn't think to do it against the SVN repo, I don't know, but I didn't). The patch doesn't apply for me either so scrap this one and I'll submit a new one against the head of SVN. Sorry about that. On 10/2/23 20:27, Greg Hellings wrote: Aaron, Your patch fails to apply against the head of SVN for me, with this error: @ patch -p1 < ../aaron-rainbolt.patch patching file bindings/swig/oldmake/Makefile.am Hunk #1 FAILED at 76. 1 out of 1 hunk FAILED -- saving rejects to file bindings/swig/oldmake/Makefile.am.rej patching file bindings/swig/package/Makefile.am Hunk #1 FAILED at 84. 1 out of 1 hunk FAILED -- saving rejects to file bindings/swig/package/Makefile.am.rej can't find file to patch at input line 35 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |diff --git a/bindings/swig/package/Makefile.in |b/bindings/swig/package/Makefile.in |index b5f05c9..370a9e7 100644 |--- a/bindings/swig/package/Makefile.in |+++ b/bindings/swig/package/Makefile.in -- File to patch: Furthermore, it looks like you are patching the autotools build system, which is not supported in the Python and Perl bindings. Those are only supported building through the CMake files. At least, they aren't supported by me as I don't go near autotools, and last I knew I was the only one working in the Swig bindings. I don't know why your patch is failing to apply, as I don't believe there should be any drift in those Makefiles. I'd be happy to try again if you have any advice as to why the patch is not applying. --Greg On Thu, Sep 28, 2023 at 11:53 AM Aaron Rainbolt wrote: Good morning/evening, and thanks for your time. As distutils has been deprecated and finally removed in Python 3.12, SWORD is unable to build in Fedora without the following patch. The patch: * Replaces all references to distutils with their setuptools equivalents. * Modifies the build system to allow specifying a new CMake argument, "SWORD_PYTHON_INSTALL_ROOT", which allows setting the installation path for the Python bindings without generating a Python egg. (This is necessary since Python eggs have been deprecated as well and will likely be removed later. See https://github.com/pypa/setuptools/issues/3143 - specifying both a --root and a --prefix to the setup.py scripts seems to work around this issue.) All contributions in this patch are made available to the SWORD Project under the terms of the GNU General Public License version 2. Thanks for your consideration, and have a blessed day! Aaron (P.S. - the reason this appears to be a Git patch is because I used Git to let me generate a multi-file patch more easily. I realize SWORD uses SVN, sorry if this looks confusing.) From 07b31a74ea920077fa0d69cdab2ab188dd17b322 Mon Sep 17 00:00:00 2001 From: Aaron Rainbolt Date: Wed, 27 Sep 2023 10:51:27 -0600 Subject: [PATCH] Migrate to setuptools --- bindings/swig/oldmake/Makefile.am | 2 +- bindings/swig/package/Makefile.am | 3 +-- bindings/swig/package/Makefile.in | 3 +-- bindings/swig/python/CMakeLists.txt | 7 +-- 4 files changed, 8 insertions(+), 7 deletions(-) diff --git a/bindings/swig/oldmake/Makefile.am b/bindings/swig/oldmake/Makefile.am index 45a37ef..789813b 100644 --- a/bindings/swig/oldmake/Makefile.am +++ b/bindings/swig/oldmake/Makefile.am @@ -76,7 +76,7 @@ python_makebuild: $(PYTHONSWIG) echo "writing python/setup.py" @echo "#! /usr/bin/python" > python/setup.py @echo "" >> python/setup.py - @echo "from distutils.core import setup, Extension" >> python/setup.py + @echo "from setuptools import setup, Extension" >> python/setup.py @echo "setup (name = \"sword\"," >> p
Re: [sword-devel] [PATCH] Migrate setup.py files from using distutils to using setuptools
I realize these are autotools files, but they are somehow getting pulled
into the CMake build process. The spec file for the Fedora build is
still using CMake, the build was failing because of an attempt to use
distutils rather than setuptools, and the only places where distutils
was mentioned was in Python scripts embedded into the Autotools files.
Patching them fixed the problem, so I assume the CMake builds must be
using those files to generate the Python scripts for installing the
Python bindings.
I realize now that my patch was against the 1.9.0 tarball, not against
the latest SVN revision (why I didn't think to do it against the SVN
repo, I don't know, but I didn't). The patch doesn't apply for me either
so scrap this one and I'll submit a new one against the head of SVN.
Sorry about that.
On 10/2/23 20:27, Greg Hellings wrote:
Aaron,
Your patch fails to apply against the head of SVN for me, with this error:
@ patch -p1 < ../aaron-rainbolt.patch
patching file bindings/swig/oldmake/Makefile.am
Hunk #1 FAILED at 76.
1 out of 1 hunk FAILED -- saving rejects to file
bindings/swig/oldmake/Makefile.am.rej
patching file bindings/swig/package/Makefile.am
Hunk #1 FAILED at 84.
1 out of 1 hunk FAILED -- saving rejects to file
bindings/swig/package/Makefile.am.rej
can't find file to patch at input line 35
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|diff --git a/bindings/swig/package/Makefile.in
|b/bindings/swig/package/Makefile.in
|index b5f05c9..370a9e7 100644
|--- a/bindings/swig/package/Makefile.in
|+++ b/bindings/swig/package/Makefile.in
--
File to patch:
Furthermore, it looks like you are patching the autotools build
system, which is not supported in the Python and Perl bindings. Those
are only supported building through the CMake files. At least, they
aren't supported by me as I don't go near autotools, and last I knew I
was the only one working in the Swig bindings.
I don't know why your patch is failing to apply, as I don't believe
there should be any drift in those Makefiles. I'd be happy to try
again if you have any advice as to why the patch is not applying.
--Greg
On Thu, Sep 28, 2023 at 11:53 AM Aaron Rainbolt
wrote:
Good morning/evening, and thanks for your time.
As distutils has been deprecated and finally removed in Python 3.12,
SWORD is unable to build in Fedora without the following patch.
The patch:
* Replaces all references to distutils with their setuptools
equivalents.
* Modifies the build system to allow specifying a new CMake argument,
"SWORD_PYTHON_INSTALL_ROOT", which allows setting the installation
path
for the Python bindings without generating a Python egg. (This is
necessary since Python eggs have been deprecated as well and will
likely
be removed later. See
https://github.com/pypa/setuptools/issues/3143 -
specifying both a --root and a --prefix to the setup.py scripts
seems to
work around this issue.)
All contributions in this patch are made available to the SWORD
Project
under the terms of the GNU General Public License version 2.
Thanks for your consideration, and have a blessed day!
Aaron
(P.S. - the reason this appears to be a Git patch is because I
used Git
to let me generate a multi-file patch more easily. I realize SWORD
uses
SVN, sorry if this looks confusing.)
From 07b31a74ea920077fa0d69cdab2ab188dd17b322 Mon Sep 17 00:00:00 2001
From: Aaron Rainbolt
Date: Wed, 27 Sep 2023 10:51:27 -0600
Subject: [PATCH] Migrate to setuptools
---
bindings/swig/oldmake/Makefile.am | 2 +-
bindings/swig/package/Makefile.am | 3 +--
bindings/swig/package/Makefile.in | 3 +--
bindings/swig/python/CMakeLists.txt | 7 +--
4 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/bindings/swig/oldmake/Makefile.am
b/bindings/swig/oldmake/Makefile.am
index 45a37ef..789813b 100644
--- a/bindings/swig/oldmake/Makefile.am
+++ b/bindings/swig/oldmake/Makefile.am
@@ -76,7 +76,7 @@ python_makebuild: $(PYTHONSWIG)
echo "writing python/setup.py"
@echo "#! /usr/bin/python" > python/setup.py
@echo "" >> python/setup.py
- @echo "from distutils.core import setup, Extension" >>
python/setup.py
+ @echo "from setuptools import setup, Extension" >>
python/setup.py
@echo "setup (name = \"sword\"," >> python/setup.py
@echo " version = \"$(VERSION)\"," >> python/setup.py
@echo " maintainer = \"Sword Developers\"," >>
python/setup.py
diff --git a/bindings/swig/package/Makefile.am
b/bindings/swig/package/Makefile.am
index 14
Re: [sword-devel] Resuming the development of Xiphos - introducing xiphos-ng (Was: Licensing audit of SWORD for Fedora - sharing results with upstream)
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 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=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 us
[sword-devel] Resuming the development of Xiphos - introducing xiphos-ng (Was: Licensing audit of SWORD for Fedora - sharing results with upstream)
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=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
Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream
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=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! 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 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 l
Re: [sword-devel] A replacement for ftpparse
This is no longer necessary - the original ftpparse is now public-domain where possible, and truly open-source elsewhere. See https://cr.yp.to/distributors.html "What are the distribution terms for ftpparse?" On 9/29/23 04:00, Aaron Rainbolt wrote: For those who have read the earlier discussion about the license audit, I wanted to do something to help with the presence of the non-free ftpparse code in SWORD. This is my initial attempt: https://github.com/ArrayBolt3/FreeFTPParser While this parser only can handle UNIX LIST output, I believe this should be sufficient at least to begin with since I haven't been able to even find documentation on the other formats, or even publicly available servers that use those other formats (though admittedly my search wasn't too deep). I'm pretty sure ftp.crosswire.org uses the UNIX format (it sure looks like it if I browse around using BSD ftp, which shipped with my Kubuntu installation). FreeFTPParser is API-compatible with the original ftpparse - the idea is that the new ftpparse.h and ftpparse.c can be dropped in place of the old ones and everything should just work. This library needs A LOT of testing before it can be deployed in actual use, but it seems to not instantly fall over and segfault if you feed it corrupted data. Consider it alpha-quality. I'll be doing more testing in the coming days Lord willing (I might even try to build it into SWORD and see what happens :D). Anyway, hopefully this should provide a way to get ftpparse out of SWORD. I licensed it as 0BSD since that allows pretty much anyone to do anything with it (so it should be usable anywhere ftpparse is currently in use), but if the SWORD devs would prefer, I'd be happy to make it GPLv2 instead. Hope this is useful! Have a blessed day! Aaron ___ 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] Fwd: Licensing audit of SWORD for Fedora - sharing results with upstream
Gah, forgot to use Reply List in Thunderbird. Forwarded Message Subject: Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream Date: Fri, 29 Sep 2023 11:01:12 -0500 From: Aaron Rainbolt To: Greg Hellings On 9/28/23 11:29, Greg Hellings wrote: On Thu, Sep 28, 2023, 12:14 Aaron Rainbolt wrote: 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 :) There are others who are pumpkin holders for separate parts and they'll need to decide on updating their pieces. I own CMake and the Swig bindings (Python and Perl for us). 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=markup <https://svn.filezilla-project.org/filezilla/FileZilla3/trunk/src/engine/directorylistingparser.cpp?revision=10945=markup>). We could port the logic from that into something SWORD-compatible perhaps? That would probably work. Part of the goal with SWORD is that it needs no hard external library dependencies. Thus why ftpparse has been included inline. A novel contribution that replaces those but is still highly portable C would likely be welcomed. I wrote an implementation of ftpparse that worked for UNIX LIST output and seemed to work, but it looks like it will no longer be needed. I requested that D. J. Bernstein relicense it to something open-source, and this is the result: https://cr.yp.to/distributors.html (see the section "What are the distribution terms for ftpparse?") It's now public-domain and can be used under any of four different licenses, all of which are GPLv2 compatible and three of which are Fedora-compatible. So ftpparse is officially no longer a concern. That was the last hurdle for getting SWORD back into Fedora :D - Aaron 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? I don't believe I had to modify anything. They were simply pulled in so I could maintain support for old versions of CMake - like on CentOS 6 and old Ubuntu LTS versions at the time - that had the core functionality needed but just lacked a file which newer CMake had bundled. Including most of them is likely a moot point by now as those versions are ancient. Yes, I undoubtedly modified it from FindBZIP2 as it was a later addition to the optional dependencies. The only reason to upgrade to GPL2 is that it's the exclusive license and version for SWORD contributions, in absence of compelling reasons to the contrary. 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. I'm fairly certain that I am. If not the owner I was the defacto maintainer. You are welcome to take over those packages, for sure. Let me know if you need me to do the needful for that. I don't think they've been officially orphaned for F39, but would be on the chopping block for F40 in the absence of sword making it back in. --Greg 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 F
[sword-devel] A replacement for ftpparse
For those who have read the earlier discussion about the license audit, I wanted to do something to help with the presence of the non-free ftpparse code in SWORD. This is my initial attempt: https://github.com/ArrayBolt3/FreeFTPParser While this parser only can handle UNIX LIST output, I believe this should be sufficient at least to begin with since I haven't been able to even find documentation on the other formats, or even publicly available servers that use those other formats (though admittedly my search wasn't too deep). I'm pretty sure ftp.crosswire.org uses the UNIX format (it sure looks like it if I browse around using BSD ftp, which shipped with my Kubuntu installation). FreeFTPParser is API-compatible with the original ftpparse - the idea is that the new ftpparse.h and ftpparse.c can be dropped in place of the old ones and everything should just work. This library needs A LOT of testing before it can be deployed in actual use, but it seems to not instantly fall over and segfault if you feed it corrupted data. Consider it alpha-quality. I'll be doing more testing in the coming days Lord willing (I might even try to build it into SWORD and see what happens :D). Anyway, hopefully this should provide a way to get ftpparse out of SWORD. I licensed it as 0BSD since that allows pretty much anyone to do anything with it (so it should be usable anywhere ftpparse is currently in use), but if the SWORD devs would prefer, I'd be happy to make it GPLv2 instead. Hope this is useful! Have a blessed day! Aaron ___ 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] [PATCH] Migrate setup.py files from using distutils to using setuptools
Good morning/evening, and thanks for your time.
As distutils has been deprecated and finally removed in Python 3.12,
SWORD is unable to build in Fedora without the following patch. The patch:
* Replaces all references to distutils with their setuptools equivalents.
* Modifies the build system to allow specifying a new CMake argument,
"SWORD_PYTHON_INSTALL_ROOT", which allows setting the installation path
for the Python bindings without generating a Python egg. (This is
necessary since Python eggs have been deprecated as well and will likely
be removed later. See https://github.com/pypa/setuptools/issues/3143 -
specifying both a --root and a --prefix to the setup.py scripts seems to
work around this issue.)
All contributions in this patch are made available to the SWORD Project
under the terms of the GNU General Public License version 2.
Thanks for your consideration, and have a blessed day!
Aaron
(P.S. - the reason this appears to be a Git patch is because I used Git
to let me generate a multi-file patch more easily. I realize SWORD uses
SVN, sorry if this looks confusing.)
From 07b31a74ea920077fa0d69cdab2ab188dd17b322 Mon Sep 17 00:00:00 2001
From: Aaron Rainbolt
Date: Wed, 27 Sep 2023 10:51:27 -0600
Subject: [PATCH] Migrate to setuptools
---
bindings/swig/oldmake/Makefile.am | 2 +-
bindings/swig/package/Makefile.am | 3 +--
bindings/swig/package/Makefile.in | 3 +--
bindings/swig/python/CMakeLists.txt | 7 +--
4 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/bindings/swig/oldmake/Makefile.am
b/bindings/swig/oldmake/Makefile.am
index 45a37ef..789813b 100644
--- a/bindings/swig/oldmake/Makefile.am
+++ b/bindings/swig/oldmake/Makefile.am
@@ -76,7 +76,7 @@ python_makebuild: $(PYTHONSWIG)
echo "writing python/setup.py"
@echo "#! /usr/bin/python" > python/setup.py
@echo "" >> python/setup.py
- @echo "from distutils.core import setup, Extension" >> python/setup.py
+ @echo "from setuptools import setup, Extension" >> python/setup.py
@echo "setup (name = \"sword\"," >> python/setup.py
@echo " version = \"$(VERSION)\"," >> python/setup.py
@echo " maintainer = \"Sword Developers\"," >> python/setup.py
diff --git a/bindings/swig/package/Makefile.am
b/bindings/swig/package/Makefile.am
index 14500c3..f44974d 100644
--- a/bindings/swig/package/Makefile.am
+++ b/bindings/swig/package/Makefile.am
@@ -84,8 +84,7 @@ python_makebuild: $(PYTHONSWIG)
echo "writing python/setup.py"
@echo "#! /usr/bin/python" > python/setup.py
@echo "" >> python/setup.py
- @echo "from distutils.core import setup" >> python/setup.py
- @echo "from distutils.extension import Extension" >> python/setup.py
+ @echo "from setuptools import setup, Extension" >> python/setup.py
@echo "import commands" >> python/setup.py
@echo "" >> python/setup.py
@echo "def pkgconfig(*packages, **kw):" >> python/setup.py
diff --git a/bindings/swig/package/Makefile.in
b/bindings/swig/package/Makefile.in
index b5f05c9..370a9e7 100644
--- a/bindings/swig/package/Makefile.in
+++ b/bindings/swig/package/Makefile.in
@@ -938,8 +938,7 @@ python_makebuild: $(PYTHONSWIG)
echo "writing python/setup.py"
@echo "#! /usr/bin/python" > python/setup.py
@echo "" >> python/setup.py
- @echo "from distutils.core import setup" >> python/setup.py
- @echo "from distutils.extension import Extension" >> python/setup.py
+ @echo "from setuptools import setup, Extension" >> python/setup.py
@echo "import commands" >> python/setup.py
@echo "" >> python/setup.py
@echo "def pkgconfig(*packages, **kw):" >> python/setup.py
diff --git a/bindings/swig/python/CMakeLists.txt
b/bindings/swig/python/CMakeLists.txt
index cbb4058..247bc79 100644
--- a/bindings/swig/python/CMakeLists.txt
+++ b/bindings/swig/python/CMakeLists.txt
@@ -25,7 +25,7 @@ ENDIF(NOT PYTHONLIBS_FOUND)
SET(PY_SCRIPT "#!${PYTHON_EXECUTABLE}
-from distutils.core import setup, Extension
+from setuptools import setup, Extension
setup(
name='sword',
version='${SWORD_VERSION}',
@@ -51,8 +51,11 @@
ADD_CUSTOM_TARGET(swordswig_python${SWORD_PYTHON_VERSION} ALL
WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
# Allow user installation to custom directory
+IF(NOT SWORD_PYTHON_INSTALL_ROOT STREQUAL "")
+ SET(SETUP_ARGS "\"--root=${SWORD_PYTHON_INSTALL_ROOT}\"")
+ENDIF(NOT SWORD_PYTHON_INSTALL_ROOT STREQUAL "")
IF(NOT SWORD_PYTHON_INSTALL_DIR STREQUAL "")
-
Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream
On 9/28/23 11:29, Greg Hellings wrote: On Thu, Sep 28, 2023, 12:14 Aaron Rainbolt wrote: 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 :) There are others who are pumpkin holders for separate parts and they'll need to decide on updating their pieces. I own CMake and the Swig bindings (Python and Perl for us). Ah, that makes perfect sense to me. I'll send the patch for the Python stuff soon. 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=markup <https://svn.filezilla-project.org/filezilla/FileZilla3/trunk/src/engine/directorylistingparser.cpp?revision=10945=markup>). We could port the logic from that into something SWORD-compatible perhaps? That would probably work. Part of the goal with SWORD is that it needs no hard external library dependencies. Thus why ftpparse has been included inline. A novel contribution that replaces those but is still highly portable C would likely be welcomed. Great, that will probably be the next thing I work on then. 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? I don't believe I had to modify anything. They were simply pulled in so I could maintain support for old versions of CMake - like on CentOS 6 and old Ubuntu LTS versions at the time - that had the core functionality needed but just lacked a file which newer CMake had bundled. Including most of them is likely a moot point by now as those versions are ancient. Yes, I undoubtedly modified it from FindBZIP2 as it was a later addition to the optional dependencies. The only reason to upgrade to GPL2 is that it's the exclusive license and version for SWORD contributions, in absence of compelling reasons to the contrary. The only reason I'm reticent to simply say "everything here is GPL2" is because of the following clause in Fedora's policies: > The License: field is meant to provide a simple enumeration of the licenses found in the source code that are reflected in the binary package. **No further analysis should be done regarding what the "effective" license is, such as analysis based on theories of GPL interpretation or license compatibility or suppositions that “top-level” license files somehow negate different licenses appearing on individual source files.** There is no agreed-upon set of criteria or rules under which one can make conclusions about “effective” licenses or reduce composite license expressions to something simpler. (From https://docs.fedoraproject.org/en-US/legal/license-field/) The page goes into further detail, emphasizing that glossing over any license in the project is not allowed, even if the project's "effective" license is something else. As I want everything to go as smoothly as possible, I don't want to say "this file that says it's BSD-3-Clause is really GPLv2" unless there's been actual modifications to the file by SWORD contributors that are undeniably GPLv2 licensed. In that instance, ideally SWORD upstream would include notices on files that were modified in this way to avoid doubt about what files can be used how (since otherwise the file just says "this is BSD licensed" and someone may try to use it as such). That being said, I guess even if the files were "upgraded", they still came from (and therefore contain some) BSD/BSL/whatever else code, so it's valid to list their licenses in the spec file even if they aren't entirely what they say they are. I can discuss that with the Fedora developers so that everything goes as smoothly as possible. Aaron Thanks so much for your help! Also, did you also previously maintain Xiphos and Bibletime? If so, I would love to take maintainership of
Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream
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=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. 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 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: - ObjCSw
[sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream
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
