[xiphos-devel] Note

[Greg Hellings]

Word to the wise.

https://bugzilla.redhat.com/show_bug.cgi?id=1375845

Fedora is officially deprecating and removing WebKitGTK+ versions that
expose and use webkit1's API because it was deprecated in 2013 and has
over 150 unfixed security vulnerabilities. If dependent packages do
not update by the time Fedora 26 is released, they will not be present
in that release as the WebKitGTK package will be removed in that
version (webkitgtk3, specifically, for those keeping track).

The recommended solution is to move to the webkit2 API, which is
maintained and will be retained in Fedora. (This is available as the
webkitgtk4 package, for those of you trying to keep track of package
names)

Caveat Coder: The webkit2 API is only available in GTK+ 3 builds of
WebKitGTK+ and has no support in GTK+ 2, which will mean we need to
stop shipping the xiphos-gtk2 package and be ready to fully embrace
GTK+ 3.

Caveat Coder 2: The webkit2 API, even with WebKitGTK+ 4, is supposedly
not supported on Windows, nor will it ever be. I don't know if the
mingw-webkitgtk3 package will be maintained in Fedora, but I imagine
it will go away along with its friend eventually. The Fedora team's
response to people who need to support both targets is, essentially,
"Good luck."

I'm working to update the official rawhide build right now, to make
sure that it at least builds. I don't have a rawhide machine on hand,
though, if anyone runs Rawhide and can test my builds, I would be most
appreciative.

--Greg

___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] Note

[Greg Hellings]

Yes, this is a most annoying thing. I really have no visibility into
any of the decisions and why they were made on the WebKitGTK side or
such. I just need to react to this threat of pulling Xiphos out of the
repository.

For anyone with access to Rawhide, here is the link to the scratch
build I did switching out to the wk2 API and activating the webkit
editor as well.
https://koji.fedoraproject.org/koji/taskinfo?taskID=15710762

Follow the sub-build links there to your architecture, and give the
xiphos-common and xiphos-gtk3 RPMs a download and install. Let me know
if there's anything wrong with the builds themselves.

--Greg

On Tue, Sep 20, 2016 at 6:43 AM, Karl Kleinpaste  wrote:
> On 09/19/2016 05:39 PM, Greg Hellings wrote:
>
> The recommended solution is to move to the webkit2 API
>
> Yes, there was discussion of this in #xiphos a week or so ago, though with
> regard to Ubuntu.
>
> The WK2 configuration builds, runs without crashing...and looks like total
> crap. I don't know what they did to it in the last year but basic operations
> that have been in place for something like 10 years now render a main window
> that is crippled.  Chris Bayliss says it's not WK2 itself but our packing of
> GTK widgets -- I dunno, it seems to me that Everything Worked Just Fine for
> an indecently long time, considering that even today it looks right and
> works correctly with plain old WK, but now the upgrade treadmill has us
> looking yet again at a toolkit change.  Considering the differences required
> for WK2 over WK, WK2 becomes the 6th display toolkit used by
> GnomeSword/Xiphos in 15 years.  This gets old.
>
> Yes, it will have to be dealt with. Comedy is not pretty. A related problem
> is that the editor component was not ported to WK2 because at the time Chris
> couldn't find adequate documentation of its API, as to its differences from
> original WK. That is, at the moment, the latest-hotness WK2 build still uses
> the GTKHTML editor.  Incongruous, I know.  Funny, perhaps, but oddly enough
> it works. Er, worked until WK2 went off the deep end.
>
> (Why does WK2 have any API differences from WK?  What benefit is reaped from
> gratuitously ripping up an interface?  Why could not the internal
> re-implementation still present an identical application-facing interface?
> -- Eh, don't answer that, I already know.)
>
> https://github.com/crosswire/xiphos/issues/756
>
> I have a politically incorrect yet tractable plan for how to deal with
> Win32.
>
> --karl
>
>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>

___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] Xiphos 4.0.5

[Greg Hellings]

Versions of Xiphos have been built into the standard repositories for
Rawhide, Fedora 26 (current alpha - will be available in 3 days in
updates), and Fedora 25 (current stable - will be available in 7 days in
updates).

--Greg

On Sun, Apr 23, 2017 at 8:32 PM, Karl Kleinpaste 
wrote:

> An act of desperation.
>
> A week or so ago, I was informed of a heinous first-time user module
> manager bug.  This has been lurking for some 18 months; I am alarmed that
> no one noticed or reported it sooner. This release is for that fix; no
> significant new capability.
>
> https://github.com/crosswire/xiphos/releases/tag/4.0.5
>
> There are my usual distribution formats: source tar.gz, Fedora RPM, Win
> 32/64 .exe (32 recommended), Ubuntu binary tree tar.gz (until packager gets
> around to *.deb).
>
> My other desperation is that we haven't had an engine release in 2.5 years.
>
> --karl
>
> Release 4.0.5
> 23 Apr 2017
>
> - ReadAloud: Speak verse# only if we are showing verse# in text as well.
> - Fix crash caused by lack of collator during mod.mgr in first run.
>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] an idea for the future of xiphos

[Greg Hellings]

On Sun, Apr 23, 2017 at 10:43 PM, Christopher Bayliss <
christopher.j.bayl...@gmail.com> wrote:

> The recent release made me think about this. :)
>
> I imagine the GTK3 support must be pretty bad now as there have been a
> lot of API changes, but I haven't used xiphos in awhile, life has been
> **very busy**. So I was thinking about a way to make it easier to use
> newer GUI toolkits:
>

It still compiles just fine against the latest versions of GTK 3. So long
as you aren't asking for the WebKit based editor with the WebKit2 API, then
you can definitely get the job done with GTK3. As for how it looks or
works, I have no idea on that.


> We could separate out all the cool features of xiphos that are not GUI
> related and put them into a library called libxiphos.
>

This is the route that BibleTime took. It is now available with at least 3
different front ends - one on Mac/Windows/Linux, the other two on Android.
The separation was good for allowing multiple frontends, but also good for
cleaning up and better defining the code within the application. I don't
think that libbibletime is a uniquely installable artifact, but it's built
as a separate step before the selected GUI is compiled onto the application.


>
> Then write a new frontend in, for example, python and GTK3. Or not. If
> we have libxiphos, it would be easier to use an entirely different
> toolkit, like Qt5.
>

I would suggest moving away from Python for this complex of an application.
All moving to Python would do for us is make it harder to detect problems
as the toolkits shift out from under our feet.


> I guess my point is it will get harder to maintain the GTK3 part of
> Xiphos as they change the way it works more with each release, meaning
> we are going to have to rewrite the way we use the GTK3 API anyway.
> However it looks like the GTK team is working on a plan to make this
> easier:
>
> https://blog.gtk.org/2016/09/01/versioning-and-long-term-
> stability-promise-in-gtk/
>
> IDK if my idea is a good solution, but I believe we are going to have to
> figure something out, so I proposing it anyway. :) One of the advantages
> of using a scripting language like python to write the frontend in is,
> it would be fast to write. (I hate python, but I see it's uses) And if
> we have libxiphos, which would be largely c and c++, we wouldn't have
> any of the performance issues that python commonly brings with it.
>

The problems with Python are much less about performance than about
maintainability across a large code base. Consistently, across all
software, the larger the code base, the better are the results and impacts
of sticking with a language that has a discrete compile step and explicit
typing, type checking, argument checking, etc. Moving backwards,
intentionally, from C/C++ to Python would be to give up all the current
warnings and alerts that tell us when our underlying widget library has
shifted.

I think the biggest thing that would benefit us in the planning is to setup
a matrix of what combinations of libraries and toolkits do we depend on,
and which ones do we absolutely need. Currently we have multiple versions
of GTK2 that are supported, several versions of GTK3 that are supported,
WebKit or WebKit2 for display, WebKit or GTKHTML for edit, and we have
support for either Windows or Linux and an outstanding request for Mac OS X
support.

We should endeavor to minimize this matrix. For instance, I would propose
we move entirely to a single display technology and drop support for older
versions: drop support moving forward towards 4.1 for all GTKHTML and all
WebKit1 technology; completely eliminate any GTK version below 3.20 (as
this is currently the latest we check for). Perhaps we have to keep one
additional set of displays for Windows, but we should not try to support
that technology also on Linux if it does not come for free with the
supported Linux implementation.

If we could do that, then building and improving and moving forward would
be much easier. As it presently stands, it is very difficult to build a
build anything remotely resembling a unified experience for Xiphos across
even just the two biggest distros (Ubuntu 17.04 and Fedora 26) as Fedora is
dropping support for WebKit1 which means the Xiphos editor needs GTKHTML to
run on the newest Fedora but Ubuntu 17.04 doesn't offer gtkhtml support and
so the editor must be built with WebKit1. Both of those experiences could
be unified if we had a WebKit2-based editor. That is, if such a thing is
possible.

--Greg
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

[xiphos-devel] TravisCI

[Greg Hellings]

Since we're on the Github infrastructure now, we can avail ourselves of
some of the other nice benefits out there for OpenSource software.
Specifically, I've just put in some effort to create a branch that includes
integration with Travis CI (travis-ci.org). Karl, if you're able to turn on
Travis CI builds for the main repository (I'm not an admin on the Github
repo, so I can't enable it), I can submit my PR and you can see what Travis
CI can give us. In this case, I have it test building Xiphos on Fedora 25,
Fedora Rawhide, CentOS 7, Ubuntu 17.04, and Ubuntu 16.04 LTS. Other
distributions can be added in the future, as can testing the Windows
builds, etc.

If we really wanted to, we can even go so far as to configure Travis CI to
build and deploy the various artifacts that are part of each release, like
the Windows installers, the Fedora RPMs, etc. I've just recently done this
for one of my projects at work, and it's gone along flawlessly so far. All
I have to do is tag a commit in git, and not only does the CI build, but
the CD piece fires to upload the build artifacts to their proper
destination.

But, for the time being, the current build matrix can give us a bit of
sanity that builds on the latest of the three major distributions are
executing properly.

--Greg
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] runtime failure to find imagemagick

[Greg Hellings]

You might check your package manager to see if it's an optional package
that ImageMagick can provide?

On Tue, May 23, 2017 at 5:29 PM, Karl Kleinpaste 
wrote:

> On 05/23/2017 03:37 PM, Peter von Kaehne wrote:
>
> Sorry, git-head or whatever it is called ..
>
> Well, OK... The ImageMagick dependency has been gone since 3.1.2, in 2009.
> And consequently the only uses of the word "convert" under the src subtree
> are related to XML needs, date/time conversions, settings, and string/int
> conversions. So I'm as confused as you.
>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] download counts

[Greg Hellings]

Doesn't look like they have a way on their UI to do it, but you can use
this information for the purpose:

https://help.github.com/articles/getting-the-download-count-for-your-releases/

Processing this for the latest release can be done as follows:
curl -X GET https://api.github.com/repos/crosswire/xiphos/releases | jq
'.[0].assets[] | .name, .download_count'

This requires the "jq" tool, which is similar to awk/sed/grep for
processing JSON formatted data. It is a 0-depdendency C program available
from Fedora repos. I get the following output for this command, at present:

"xiphos-4.0.6-20170810-win32.exe"
4
"xiphos-4.0.6-20170810-win64.exe"
6
"xiphos-4.0.6-20170810.tar.gz"
16
"xiphos-common-4.0.6-1xi.fc24.i686.rpm"
0
"xiphos-common-4.0.6-1xi.fc24.x86_64.rpm"
3
"xiphos-debuginfo-4.0.6-1xi.fc24.i686.rpm"
0
"xiphos-debuginfo-4.0.6-1xi.fc24.x86_64.rpm"
0
"xiphos-gtk2-4.0.6-1xi.fc24.i686.rpm"
0
"xiphos-gtk2-4.0.6-1xi.fc24.x86_64.rpm"
0
"xiphos-gtk3-4.0.6-1xi.fc24.i686.rpm"
0
"xiphos-gtk3-4.0.6-1xi.fc24.x86_64.rpm"
3
"xiphos.spec"
2

--Greg

On Sat, Aug 12, 2017 at 11:03 AM, Karl Kleinpaste 
wrote:

> SF provided histograms of download activity, providing useful indicators
> of who looked for what.
>
> Does GH provide similar capability?
>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] download counts

[Greg Hellings]

If you're not interested in breaking out each element, and only want a
total download count, you can use this filter, instead:

curl -X GET https://api.github.com/repos/crosswire/xiphos/releases | jq
'[.[0].assets[] | .download_count] | add'

--Greg

On Sat, Aug 12, 2017 at 12:43 PM, Greg Hellings 
wrote:

> Doesn't look like they have a way on their UI to do it, but you can use
> this information for the purpose:
>
> https://help.github.com/articles/getting-the-download-
> count-for-your-releases/
>
> Processing this for the latest release can be done as follows:
> curl -X GET https://api.github.com/repos/crosswire/xiphos/releases | jq
> '.[0].assets[] | .name, .download_count'
>
> This requires the "jq" tool, which is similar to awk/sed/grep for
> processing JSON formatted data. It is a 0-depdendency C program available
> from Fedora repos. I get the following output for this command, at present:
>
> "xiphos-4.0.6-20170810-win32.exe"
> 4
> "xiphos-4.0.6-20170810-win64.exe"
> 6
> "xiphos-4.0.6-20170810.tar.gz"
> 16
> "xiphos-common-4.0.6-1xi.fc24.i686.rpm"
> 0
> "xiphos-common-4.0.6-1xi.fc24.x86_64.rpm"
> 3
> "xiphos-debuginfo-4.0.6-1xi.fc24.i686.rpm"
> 0
> "xiphos-debuginfo-4.0.6-1xi.fc24.x86_64.rpm"
> 0
> "xiphos-gtk2-4.0.6-1xi.fc24.i686.rpm"
> 0
> "xiphos-gtk2-4.0.6-1xi.fc24.x86_64.rpm"
> 0
> "xiphos-gtk3-4.0.6-1xi.fc24.i686.rpm"
> 0
> "xiphos-gtk3-4.0.6-1xi.fc24.x86_64.rpm"
> 3
> "xiphos.spec"
> 2
>
> --Greg
>
> On Sat, Aug 12, 2017 at 11:03 AM, Karl Kleinpaste 
> wrote:
>
>> SF provided histograms of download activity, providing useful indicators
>> of who looked for what.
>>
>> Does GH provide similar capability?
>>
>> ___
>> xiphos-devel mailing list
>> xiphos-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>>
>>
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] need an opinion on release

[Greg Hellings]

As I doubt anyone is actually building for Windows besides you, I would
just make a Windows build. If it crops up in any other environments, then
you can cut the new full release.

On Aug 20, 2017 1:22 PM, "Karl Kleinpaste"  wrote:

> I need an opinion.
>
> I have found the problem where Windows upchucks during first-time user
> module install, after refreshing crosswire. It's not a bug in the code.
> It's that I have to invoke the compilers with -fno-delete-null-pointer-checks.
> The code is fine, *IF* the @#$% compiler would stop arbitrarily
> "optimizing" certain checks into oblivion.
>
> In principle, this bug should affect all builds, because both regular and
> MinGW compilers on my Fedora boxes are 6.3.1, but experientially it seems
> to have affected Windows builds only. Do I put out an entire new release,
> 4.0.7, to be safe?  Or just a Windows release, as e.g. 4.0.6a?
>
> Comments welcome.
>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] new release by end of month

[Greg Hellings]

Looks like there's something wonky with your SWORD version, and not with
Xiphos. A header file might be missing a #ifdef guard somewhere or the like.

--Greg

On Tue, Sep 5, 2017 at 2:12 PM, Peter von Kaehne  wrote:

> On Tue, 2017-09-05 at 09:33 -0400, Karl Kleinpaste wrote:
> >
> > I hope that some on the -devel list will keep up with test building
> > and experimentation as things move along, to make sure I don't
> > introduce any unexpected quirks along the way.
>
> I had not been keeping up due to private commitments, though I saw that
> a lot of things are happening.
>
> I cloned today a fresh copy of the git repo and did try to build, but
> hit a roadblock at the linking stage. I am sure it is my mistake rather
> than anyone else's but a hint would be highly appreciated. Please see
> the log below.
>
> Thanks!
>
> Peter
>
> [133/134] cxx_link: build/default/src/examples/marshal_1.o
> build/default/src/examples/xiphos-nav_1.o ->
> build/default/src/examples/xiphos-nav
> /usr/local/lib/libsword.a(versificationmgr.o):(.data.rel.ro.local+0x0):
> multiple definition of `sword::builtin_abbrevs'
> default/src/main/prayerlists_1.o:(.data.rel.ro.local+0x0): first
> defined here
> /usr/local/lib/libsword.a(versificationmgr.o): In function
> `__gnu_cxx::new_allocator
> >::~new_allocator()':
> /home/peter/Source/sword/lib/../src/mgr/versificationmgr.cpp:61:
> multiple definition of `sword::otbooks'
> default/src/main/prayerlists_1.o:/home/peter/Source/xiphos/build/../src
> /main/prayerlists.cc:82: first defined here
> /usr/local/lib/libsword.a(versificationmgr.o): In function
> `sword::VersificationMgr::System::~System()':
> /home/peter/Source/sword/lib/../src/mgr/versificationmgr.cpp:186:
> multiple definition of `sword::ntbooks'
> default/src/main/prayerlists_1.o:/home/peter/Source/xiphos/build/../src
> /main/prayerlists.cc:184: first defined here
> /usr/local/lib/libsword.a(versificationmgr.o): In function
> `__gnu_cxx::new_allocator
> >::~new_allocator()':
> /home/peter/Source/sword/lib/../src/mgr/versificationmgr.cpp:61:
> multiple definition of `sword::vm'
> default/src/main/prayerlists_1.o:/home/peter/Source/xiphos/build/../src
> /main/prayerlists.cc:82: first defined here
> collect2: error: ld returned 1 exit status
> Waf: Leaving directory `/home/peter/Source/xiphos/build'
> Build failed:  -> task failed (err #1):
> {task: cxx_link
> locale_set_2.o,marshal_2.o,about_modules_2.o,about_sword_2.o,about_tran
> s_2.o,about_xiphos_2.o,bibletext_2.o,bibletext_dialog_2.o,bookmark_dial
> og_2.o,bookmarks_menu_2.o,bookmarks_treeview_2.o,cipher_key_dialog_2.o,
> commentary_2.o,commentary_dialog_2.o,dialog_2.o,dictlex_2.o,dictlex_dia
> log_2.o,display_info_2.o,dummy_2.o,export_bookmarks_2.o,export_dialog_2
> .o,find_dialog_2.o,font_dialog_2.o,gbs_2.o,gbs_dialog_2.o,gui_2.o,ipc_2
> .o,main_menu_2.o,main_window_2.o,menu_popup_2.o,mod_mgr_2.o,navbar_book
> _2.o,navbar_book_dialog_2.o,navbar_versekey_2.o,navbar_versekey_dialog_
> 2.o,navbar_versekey_editor_2.o,navbar_versekey_parallel_2.o,parallel_di
> alog_2.o,parallel_tab_2.o,parallel_view_2.o,preferences_dialog_2.o,sear
> ch_dialog_2.o,search_sidebar_2.o,sidebar_2.o,sidebar_dialog_2.o,splash_
> 2.o,tabbed_browser_2.o,treekey-
> editor_2.o,utilities_2.o,xiphos_2.o,gs_stringmgr_1.o,module_manager_1.o
> ,sword_main_1.o,link_dialog_1.o,editor_1.o,webkit_editor_1.o,biblesync_
> glue_1.o,configs_1.o,display_1.o,export_passage_1.o,global_ops_1.o,list
> s_1.o,main_1.o,mod_mgr_1.o,module_dialogs_1.o,modulecache_1.o,navbar_1.
> o,navbar_book_1.o,navbar_book_dialog_1.o,navbar_versekey_1.o,parallel_v
> iew_1.o,prayerlists_1.o,previewer_1.o,search_dialog_1.o,search_sidebar_
> 1.o,settings_1.o,sidebar_1.o,sword_1.o,sword_treekey_1.o,tab_history_1.
> o,url_1.o,xml_1.o,marshal_1.o,xiphos_html_1.o,marshal_1.o,wk-html_1.o
> -> xiphos}
> peter@thinkpad-x250:~/Source/xiphos$ https://github.com/crosswire/xipho
> s.git
>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] new release by end of month

[Greg Hellings]

You can use "bisect" from the known good to the known bad commit to find
the exact change.

On Sep 5, 2017 15:36, "Peter von Kaehne"  wrote:

> On Tue, 2017-09-05 at 15:41 -0400, Karl Kleinpaste wrote:
> > On 09/05/2017 03:23 PM, Greg Hellings wrote:
> > > Looks like there's something wonky with your SWORD version, and not
> > > with Xiphos.
> >  Also, the complaint is at prayerlists.cc:82, which makes no sense as
> > a point of definition for ... anything.
> >
> > That said, prayerlists.cc did gain #include of
> > sword/versificationmgr.h and sword/canon.h yesterday.
>
> Ok, I went a few iterations (e09cdf7bcae0a...) backwards and it builds
> just fine. I have not yet figured out where exactly the mistake starts
> to occur.
>
>
> Peter
>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] Xiphos 4.0.7

[Greg Hellings]

The version used to build for Fedora can be found here:
https://src.fedoraproject.org/rpms/xiphos

I haven't updated it to 4.0.7 yet since I was camping all weekend. But it
will be updated Very Soon(TM).

--Greg

On Mon, Sep 25, 2017 at 5:52 AM, Karl Kleinpaste 
wrote:

> On 09/25/2017 06:18 AM, Brian Schroeder wrote:
>
> Will a spec file for RPM builds still be available?
>
> It's there in the release area. Just be aware that it's mine, not Greg's
> (i.e. not official for Fedora or RedHat purposes), in that it still builds
> both GTK2 and GTK3 versions and installs both using the alternatives
> system. If you'd rather have the single GTK3 build without alternatives,
> get his.
>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] gtk_widget_hide() isn't hiding

[Greg Hellings]

And why aren't you just deleting it?

--Greg

On Mon, Apr 16, 2018 at 6:47 PM, Karl Kleinpaste 
wrote:

> How is it possible for this to fail to eliminate the "detach" entry from
> the main menu?
>
>widgets.attach_detach_item = UI_GET_ITEM(gxml,
> "attach_detach_sidebar");
>gtk_widget_hide(widgets.attach_detach_item);
>
> The function is called, the statements are executed, yet the menu entry
> persists.
>
> Alternatively, doing this in the UI files instead, why does this visible
> "False" not result in a hidden item?
>
> 
>   
> False
> False
> _Attach/Detach
> Sidebar
> True
>  handler="on_attach_detach_sidebar_activate"
> swapped="no"/>
>   
> 
>
> I just want the thing to go away. I don't care which mechanism is used.
> Neither one has the desired effect.
>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] Build failures

[Greg Hellings]

Rebuild sword. I don't think Xiphos will link ICU directly, but if Sword
has issues they'll appear while linking.

--Greg

On Sat, Jun 2, 2018, 16:03 Peter von Kaehne  wrote:

> Hi, I am trying to build Xiphos and fail dt my system having ICU 60.
> but the linker seems to expect ICU57.
>
> Is there a workaround?
>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] back from the dead

[Greg Hellings]

Welcome back, Mr Kleinpaste.

We missed you. 😎

On Wed, Apr 15, 2020 at 9:01 PM Karl Kleinpaste  wrote:

> At least, I think I'm back.
>
> I've been out of commission for doing Xiphos things for way too long. I'm
> back now, I think. I've just gone through ~150 emails from the github issue
> tracker. Merged a bunch of pending stuff, need to look at a few more still
> pending, made intermediate comments on many more. Working on a couple
> simple updates. Hope to get to a release point for 4.1.1 sometime Real Soon
> Now. Apologies for long absence. Life hasn't been my friend.
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] back from the dead

[Greg Hellings]

If you'd like to cry into your soup at some point, I can tell you about
what I've discovered about the state of our WebKit2 editor. Which becomes
increasingly important as more distros drop GtkHTML altogether.

In the past 3-4 releases of webkit2gtk they've moved all DOM access code
out of the main thread, so you can't even do what we do anymore. The
methods are still there, but only for the headers to a separate plugin
library to the webkit engine which you must preload before you initialize
any webkit components. What remains nebulous according to all the docs is
how to get information back and forth between the main application and the
plugin (seems you have to communicate over DBus or a similar mechanism for
systems that don't support DBus). This is drive by them moving webkit out
of the application's thread and into a subprocess of its own that
communicates back and forth with the application's GUI thread. This is
similar to how Chrome/Chromium/Blink operate and it's one way to prevent
bad things happening in the web component from happening in the main
application.

But it's gonna require some amount of ugly hackery to get that editor
working, now.

--Greg

On Wed, Apr 15, 2020 at 10:12 PM Greg Hellings 
wrote:

> Welcome back, Mr Kleinpaste.
>
> We missed you. 😎
>
> On Wed, Apr 15, 2020 at 9:01 PM Karl Kleinpaste 
> wrote:
>
>> At least, I think I'm back.
>>
>> I've been out of commission for doing Xiphos things for way too long. I'm
>> back now, I think. I've just gone through ~150 emails from the github issue
>> tracker. Merged a bunch of pending stuff, need to look at a few more still
>> pending, made intermediate comments on many more. Working on a couple
>> simple updates. Hope to get to a release point for 4.1.1 sometime Real Soon
>> Now. Apologies for long absence. Life hasn't been my friend.
>> ___
>> xiphos-devel mailing list
>> xiphos-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>>
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] back from the dead

[Greg Hellings]

Here's the magic source of Fedora building:
https://src.fedoraproject.org/rpms/xiphos/tree/master

Specifically we have 4.1.0 tarball
Plus the cmake.patch which is a massive commit corresponding to "git diff
4.1.0..fccfbdc" and pulls in the CMake build and gets rid of the waf
Plus my NASB patch

CMake incantation is:
mkdir build && cd build
export CFLAGS=-fPIC
export CXXFLAGS=-fPIC
cmake -DGTKHTML:BOOL=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo ..
make && sudo make install

--Greg

On Wed, Apr 15, 2020 at 10:35 PM Karl Kleinpaste 
wrote:

> On 4/15/20 11:18 PM, Greg Hellings wrote:
>
> it's gonna require some amount of ugly hackery to get that editor working,
> now.
>
> So my first attempts at cmake-driven build have failed because the attempt
> to build the editor chokes.
> What's the magic you're using for Fedora et al builds, to avoid including
> the editor at all for the time being?
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] back from the dead

[Greg Hellings]

On Thu, Apr 16, 2020 at 6:29 AM Karl Kleinpaste  wrote:

> On 4/15/20 11:41 PM, Greg Hellings wrote:
>
> Plus my NASB patch
>
> Of course that patch has been merged, so that can go away for next release.
>
> I see that the critical(ly dumb) thing I was missing was -DGTKHTML=ON, as
> indicated by both you and Caleb. Thanx, don't know why I didn't realize
> what that was about, it gets the gtkhtml editor. Fine so far. Duh, and all
> that.
>

You can find all the options conveniently located in
cmake/XiphosOptions.cmake to help. I keep referring back to it.


> But yours includes a ":BOOL" component. Is that a necessary or especially
> advisable cmake-ism?
>

Not strictly necessary. It just massages truthiness value such as the
Yes/No, On/Off, True/False strings into boolean value. CMake should behave
pretty well if you set them without it. It's just a tiny bit safer. Like
always wrapping shell variables in quotation marks even if you set the
value and know it doesn't have a space in it. Some day it might and you
might forget.

--Greg

> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] that blasted editor

[Greg Hellings]

If formatting is really our concern, maybe we abandon HTML editing
altogether? Perhaps a MarkDown compatible editor that will wriggle back and
forth to the HTML displays in a text?

It gives the full power of most formatting choices people would want while
not limiting the full power of HTML (you can include HTML in line in a
MarkDown document and it "just works" because md has a completely different
set of special characters but spits out HTML without escaping special
characters).

It's also very easy to convert and to read. I imagine it would be easy to
whip up an editor. And a "preview" is as easy as running text through the
processing lib and dropping it into a WebKit viewer. Observe comments on
Github that have an edit and a preview pane that are just a click apart.

It's also much more "casual user" friendly than popping open vi/vim
(default value of $EDITOR on most Linux systems). You keep consistency of
UX with the current built in editor. Libraries are very minimal and so
likely to be cross platform compatible. You can bake an editor right into a
GtkTextView or GtkSourceView with a few triggers for
bold/italics/list/quote.

I would strongly suggest considering that.

--Greg

On Fri, Apr 17, 2020, 16:39 Karl Kleinpaste  wrote:

> I've been ruminating over the editor problem for a couple days, especially
> with regard to Greg's comment, "it's gonna require some amount of ugly
> hackery to get that editor working."
>
> And I find I just can't bring myself to address that, straight up.
>
> I have found myself briefly fantasizing over simply inhaling whatever
> fraction is needed of the otherwise-outdated gtkhml library directly into
> our src/editor area, because quite honestly that editor works just fine.
> I've written a few substantial documents using it. I know others have. It's
> been a long time since I've polled users for what they want to see in
> future work, but a recurring theme over many years was "authorship
> improvements." And those requests are why we gained user annotations and
> other generative stuff. The editor never got much in the way of complaints,
> it already seemed fine to most folks.
>
> But OK, so maybe inhaling some other older library's code isn't such a hot
> idea, especially if it would represent a large bulk that isn't otherwise
> core to our purpose. We're not so much about editing as we are providing
> hooks into reading and cross-referencing. What other good editors exist,
> that don't include ... let me find some terminology suitable for family
> viewing ... having to put up with the vulgar nature of what the GTK3 people
> have done to us in so many other ways?
>
> What if we don't do an editor at all? What if instead we provide a hook
> into any external editor the user likes?
>
> It needs to be able to provide HTML content, both because that's what all
> instances of editor ever known to Xiphos have produced, and so there is
> backward compatibility with which to wrangle, but also because writing
> good-looking text requires the kind of control structures that HTML is for.
> I don't expect users actually to type  and so forth, but any editor
> that will spit out  and  and  for Xiphos to absorb
> will do what we need.
>
> Hooking into an external editor is easy in Linux. How tough is it to do in
> Windows?
>
> We could even provide a pseudo-standard set of Xiphos-"preferred" editors.
> If the user hasn't set a preference, we walk through the system, looking
> for those we like. Pick the best one found. But leave the user to set that
> preference, for those who care. We already do something like this in
> src/main/url.cc for external display of a clicked image. There's a short
> list of a few standard-available image viewers, most important of which is
> gnome-open.
>
> Seriously, lots of other applications don't depend on having their own
> editing capability. It's properly a subsystem that's farmed out to
> something else to do, something else that's good at just that. git forks
> $EDITOR (or is it $VISUAL) at the drop of a hat.
>
> I'm thinking I'd rather excise the editor entirely, rather than wade into
> that nightmare to fix it.
>
> Thoughts?
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] that blasted editor

[Greg Hellings]

On Sat, Apr 18, 2020 at 2:40 AM Dominique Corbex 
wrote:

> On Fri, 17 Apr 2020 18:32:31 -0500
> Greg Hellings  wrote:
>
> > If formatting is really our concern, maybe we abandon HTML editing
> > altogether? Perhaps a MarkDown compatible editor that will wriggle back
> and
> > forth to the HTML displays in a text?
>
> > I would strongly suggest considering that.
>
> +1
>
> I'm using marker myself
> https://github.com/fabiocolacio/Marker


I had seen that. It doesn't have any helper buttons, but I imagine we could
add one for the most basic things:

Going through the editor UI as it currently exists:

* Bold/italic/underline/strikethrough are pretty simple in Markdown
* Headings are easy
* Insert an image is also very straightforward.
* Font color/size is a bit harder
* Horizontal rule is very simple as well
* Links are pretty trivial

Tables are the only one that's moderately complex that we currently have
but wouldn't have in Markdown.

Going from MD to HTML is easy. Lots of markdown libraries exist. CMake
seems one that's already packaged for Fedora and has official MinGW build
support, so putting together a package for it seems trivial.
https://github.com/commonmark/cmark

Making the trip back from HTML to MD is a bit more complicated. There is
pandoc (https://pandoc.org/) which is written in Haskell and has a C
binding that supports ALL THE FORMATS and includes the ability to go both
directions. It does build for Windows - there are official builds released
by the pandoc folk. There is no reason to suspect a cross-compile chain
couldn't be created, but that's a lot of moving parts to put together.
Maybe it's best to include a working binary and pass temp files to it,
rather than try to include it as a library?

--Greg

>
>
> Dom
> --
> domcox 
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] that blasted editor

[Greg Hellings]

On Sat, Apr 18, 2020, 08:32 Karl Kleinpaste  wrote:

> Just to be clear... You folks are in fact suggesting excising the current
> integrated editor, to replace it with another integrated editor, just one
> that speaks a different editing scheme. You're walking the center line,
> between fixing the current nightmare-to-upgrade editor vs. removing it in
> favor of reduction to linkage to an entirely external editor.
>

Yes. I think editing in the app is the best approach and best UX for people.


> That's fine. I mean, I suppose I can roll either way, I guess. I just
> thought folks would be happier with reducing Xiphos' involvement with
> editing from "we do everything in editing" to mere external linkage at
> start ("here's the initial [usually empty] doc") and end ("let me now
> inhale the result of your editing").
>

I think, for the casual user, this would feel strange. We power users and
developers are accustomed to that workflow. But most people aren't.


> For the record, I would have never suggested literally using $EDITOR. Joe
> Random doesn't want to do styled editing in an ordinary text editor, as is
> usually indicated by $EDITOR.
>
> On 4/18/20 5:53 AM, Greg Hellings wrote:
>
> * Links are pretty trivial
>
>
> Bear in mind that links in such docs are not just external http-style
> links to external sites. The important aspect is cross-referential links,
> that is, internal links to other Sword modules. See
> http://karl.kleinpaste.org/xiphos/ and look at link-genbook*, especially
> -3. (Once upon a time, those images were a brief tutorial on how to do a
> link in Xiphos.) These create links like these:
>
> 1. Direct linkage to any other Sword module:
>  HREF="sword://Josephus/%2FThe+Antiquities+of+the+Jews%2FBook+18%2FChapter+3%2FSection+3">jos.18.3.3
>

In MarkDown this becomes:

[jos.18.3.3](sword://Josephus/%2FThe+Antiquities+of+the+Jews%2FBoom+18%2FChapter+3%2FSection+3)

Very easy for us to programmatically walk people through.


> 2. Scripture xref through the verse list:
>  HREF="passagestudy.jsp?action=showRef&type=scripRef&module=&value=Genesis+2%3A24">Genesis
> 2:24
>

Same here. This becomes:

[Genesis
2:24](passagestudy.jsp?action=showRef&type=scripRef&module=&value=Genesis+2%3A24)


>
> This takes advantage of the HTML nature in ThML's essence as
> HTML-plus-goodies. ("Goodies" are , , and .) The
> latter example exploits internal habit of how the engine's filters generate
> xref from scripRef; the former is simply an odd protocol, "sword://". No,
> these are not concepts that are portable to other Sword apps.  Er, well,
> sword:// is known in some corners other than Xiphos, and xiphos-nav
> operates on its basis.
>
> I wish I could have done xrefs as actual ThML , avoiding the
> post-filter appearance of such links, but that wasn't possible.
>

It's not likely to be possible here, either. HOWEVER, someone can enter
them directly as scripRef if we support md, and they'll be inserted to the
module that way. When they come back out, they can either stay as ThML or
we can render them to HTML and from there into MD.

Nothing says we would have to parse the result into HTML first, though.
That's part of the beauty of markdown. We can edit however we want, and let
users use a combo if they desire.


> And no, these features aren't reflective of my personal bias re: ThML.
> It's just that an editor's HTML result is best interpreted by Sword as
> ThML, exactly because of HTML-plus-goodies. HTML content makes no sense as
> any other Sword-grasped content type. If we could add an MD filter set to
> Sword directly, we could walk away from round trip MD to HTML and HTML to
> MD. But that's not going to happen.
>

We can skip the HTML entirely and leave the user editing the ThML->markdown
as is. Then things like the rendered out links aren't an issue.

And adding a MarkDown filter to the engine probably isn't very difficult at
all. MD is very simple.

--Greg

>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] that blasted editor

[Greg Hellings]

On Sat, Apr 18, 2020, 21:08 Karl Kleinpaste  wrote:

> On 4/18/20 4:14 PM, Greg Hellings wrote:
>
> And adding a MarkDown filter to the engine probably isn't very difficult
> at all.
>
> I'm not sure you realize how subtly I threw down that gauntlet, or how
> readily you picked it up. :-D
>

I don't have commit privileges to the filters. Tag, you're it. 😏😏😏

--Greg

>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] xiphos now requires very latest sword

[Greg Hellings]

>From a packaging perspective it shouldn't be difficult to pull a single
commit here and there into a new build of a release.

That doesn't help people building from source, though.

--Greg

On Sun, Apr 19, 2020 at 2:23 PM Karl Kleinpaste  wrote:

> For packagers especially, but for everyone building their own:
>
> FYI, I made a commit earlier today, attached to #845
> , that re-works the
> handling of .introMaterial in CSS controls. This gets rid of the grossness
> of a couple years ago, where I coded an ugly HTML post-delivery hack to
> remove self-closing , which I thought were erroneous. Turns out
> they're not technically wrong, if only I could convince WebKit to operate
> in XHTML mode. That in turn has proven effectively impossible and I can't
> figure out why, every suggestion made has had zero practical effect.
>
> But yesterday Troy made an accommodating change in Sword, in support of
> the idea that depending on WK sanity is unwise when it falls back to HTML
> mode too easily, so now Sword no longer generates self-closing  at
> all, instead generating milestones with . This eliminates the
> need for the post-delivery hack and I've reworked the code so that it
> behaves nicely for handling pre-book and -chapter material.
>
> This leaves Xiphos committed as a result: We cannot release a Xiphos
> update until there is a new Sword release. Now, more immediately, I have to
> get the Windows build working again anyhow, which I'm hoping won't be too
> big a challenge, but we'll see. In any event, both of these (Windows build
> and Sword release) now stand in the way of getting 4.1.1 out the door.
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] windows build

[Greg Hellings]

On Wed, Apr 22, 2020 at 10:01 PM Karl Kleinpaste 
wrote:

> I went looking into the Windows build today.
>
> The situation is very ugly. Problem is that many needed, old packages are
> no longer supported, no longer available at all. And in #963, Dom tells us
> that functional gtk3 for Windows can't be expected any time soon, so we
> won't be able to use the modern versions of these old packages.
>

The deeper I go, the more I realize there is little, if any, support for
toolkits with HTML displays that run on Windows besides Qt and wxWidgets.
GTK has completely given up and doesn't want anything to do with it.
Although WebKit supports Windows, the GTK port of it does not.


> So I went looking for other solutions. Most straightforward in appearance
> was to go to an archive of Fedora 30 packages to find the last
> mingw-webkit*.rpm before they went obsolete in F31. I've now got a copy of
> every mingw RPM from F30 including updates, and I could install any of them
> I need, except for one little detail: Some of them depend on similarly old
> packages, but those other old packages are still supported, meaning that
> more recent versions exist and are necessarily installed for other reasons.
>
> Example: We need mingw64-webkitgtk. It depends on a particular release of
> ICU. But ICU is still supported, so there exists a modern
> mingw64-icu-whatever package. I can't install the old ICU RPM that's
> compatible with mingw64-webkitgtk RPM alongside the modern ICU.
>
> What I am currently contemplating, if I can keep my stomach from
> revolting, is gathering all the needed ancient mingw packages, and putting
> them together in a special drop-in environment by extracting the packages
> with rpm2cpio. Just create a monolithic blob for our own use. That is, the
> content will be present, but not known to the system as a whole in an
> RPMish way. Update the cmake system to use a peculiar PKG_CONFIG_PATH for
> Windows that includes this blob.
>
> Comedy is not pretty.
>
> I'm wide open to countersuggestions for how to resurrect the Windows build.
>

This is exactly the situation that Containers and VMs are perfectly suited
for. Using Docker or Podman (docker isn't compatible out of the box with
F31 because of cgroupsv2 issues - it seems fixed in F32 betas that I've run
but I wouldn't swear to it) you can spin up a Fedora 30 system on top of
any running machine you want, use dnf the way it was meant to be, and
proceed onward. Is there a reason to not pursue that? This is how I build
the mingw{32,64}-sword binary files that are available on Github, even
though the build systems are running Ubuntu (both Travis CI and Github
Actions have Ubuntu as the default VM runner and don't let you select
anything else).

If you don't like Podman/Docker then a simple Vagrant vm would also be
feasible. I've considered converting the build system over to either/both
of those. It will remain frozen in time at the end of the F30 life,
whichever you choose, and avoids you needing to do whacky things like
you're contemplating. It also can make it very easy for anyone who wants to
initialize the build from their system (docker build/podman build/vagrant
up) to get it done in a single invocation.

Using Docker is probably better for compile tasks, because it doesn't incur
a virtualization penalty and it's very lightweight in terms of
requirements. And, these days, it runs on Windows as well.

The problem is that GTK2 eventually just /won't work/ in some new version
of Windows at some time in the far future. And then we'll be stuck up a
creek without a paddle.

--Greg

> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] windows build

[Greg Hellings]

Is it not just "toolbox create --image=fedora:30"? Or whatever the name is
the toolbox image is?

Regardless of that, we'd probably automate the builds on Github using bare
Docker commands.

--Greg

On Thu, Apr 23, 2020, 02:01 Dominique Corbex  wrote:

> On Wed, 22 Apr 2020 23:00:38 -0400
> Karl Kleinpaste  wrote:
>
> > Example: We need mingw64-webkitgtk.
>
> Yesterday evening, I tried to build mingw64-webkitgtk in F31, I used
> the last spec file from F30. After pages of warning, compilation
> eventually failed on error.
>
> I think it is too much time consuming to fix this and not worth the
> effort. I'm now investigating toolbox to see how to import a f30 image.
>
> Dom
> --
> domcox 
>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] windows build

[Greg Hellings]

Toolbox comes from the world where people keep trying to push containers
for everything, including the desktop. However, for automated build
release, testing, etc we'll still want to support Docker, since toolbox
isn't in the Ubuntu repositories.

Fortunately toolbox, which is built on podman, is highly compatible with
Docker and its images as well.

--Greg

On Fri, Apr 24, 2020, 02:09 Dominique Corbex  wrote:

> On Thu, 23 Apr 2020 18:24:34 -0400
> Karl Kleinpaste  wrote:
>
> > ** Creating toolbox:
> > ./xc-xiphos-win.sh: line 106: toolbox: command not found
>
> There  is no need to install docker at all, furthermore docker is not
> supported in f31 without switching back to cgroups v1.
>
> toolbox is way far more easy to use.
>
> From Fedora docs:
> The toolbox utility, which uses containers, provides an environment
> where development tools and libraries can be installed and used, it
> makes it easy to use a containerized environment for everyday software
> development and debugging.
>
> So just install toolbox:
>
> sudo dnf install toolbox
>
> See also:
> https://fedoramagazine.org/a-quick-introduction-to-toolbox-on-fedora/
>
>
> Dom
> --
> domcox 
>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] windows build

[Greg Hellings]

Maybe try skipping toolbox and going straight to Podman to test if it can
do things directly?

podman run -i -t fedora-toolbox:30 /bin/bash

--Greg

On Fri, Apr 24, 2020 at 12:01 PM Karl Kleinpaste 
wrote:

> On 4/24/20 11:59 AM, Dominique Corbex wrote:
>
> Have you disabled SELinux enabled or running Permissive mode?
>
>
> Oh, is that it?
>
> I've run with SELinux disabled since Fedora Core 3, when every update to
> selinux-policy-targeted threatened to brick my machine. selinux=0 is in my
> boot flags.
>
> I consider it a detailed practical implementation of a theoretical device
> with little practical value for me, a solution in search of a problem I
> don't have. But I don't doubt that others will have explanations for its
> worth. I get better security protection by moving sshd to a nonstandard
> port.
>
> > If you create a default toolbox:
> > $ toolbox create
> > $ toolbox enter
> > Are you facing the same issue?
>
> Yes.
>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] windows build

[Greg Hellings]

Dom,

I'm looking through xc-xiphos-win.sh and I'm curious:

Can we retool this so that it's just a regular shell script that can be
passed to Docker/podman/etc and it does the installing of deps and builds
internal to itself? Then we can easily invoke it like

(docker|podman) run -i -t -v /path/to/xiphos/source:/xiphos fedora:30
/xiphos/win32/xc-xiphos-win.sh -win32

This would make things very much easier for automating builds and allowing
people to test it locally. I don't use toolbox, but I do use Docker
regularly on Fedora 31. And most all of our cloud providers come with
Docker available out of the box, but either don't offer toolbox or it's
going to be a royal pain to get it working on their infra. I'm happy to
undertake this effort, and add it to the CI, if you don't mind.

--Greg

On Fri, Apr 24, 2020 at 12:26 PM Greg Hellings 
wrote:

> Maybe try skipping toolbox and going straight to Podman to test if it can
> do things directly?
>
> podman run -i -t fedora-toolbox:30 /bin/bash
>
> --Greg
>
> On Fri, Apr 24, 2020 at 12:01 PM Karl Kleinpaste 
> wrote:
>
>> On 4/24/20 11:59 AM, Dominique Corbex wrote:
>>
>> Have you disabled SELinux enabled or running Permissive mode?
>>
>>
>> Oh, is that it?
>>
>> I've run with SELinux disabled since Fedora Core 3, when every update to
>> selinux-policy-targeted threatened to brick my machine. selinux=0 is in my
>> boot flags.
>>
>> I consider it a detailed practical implementation of a theoretical device
>> with little practical value for me, a solution in search of a problem I
>> don't have. But I don't doubt that others will have explanations for its
>> worth. I get better security protection by moving sshd to a nonstandard
>> port.
>>
>> > If you create a default toolbox:
>> > $ toolbox create
>> > $ toolbox enter
>> > Are you facing the same issue?
>>
>> Yes.
>>
>> ___
>> xiphos-devel mailing list
>> xiphos-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>>
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] windows build

[Greg Hellings]

I have the build working in Docker, currently adding CI to it in Github
Actions. It will auto-build the artifacts (this will be step 1 of getting
automated builds out the door using Github Actions so maintainers and
release managers won't have to build the artifacts and upload them to
Github Releases anymore).

I have a question for Dom and anyone else involved: is any of the
information under the win32/ directory relevant, anymore? It looks like all
the work actually gets done in cpack/windows these days, and I've poked
around but can't find references to the rest of that code elsewhere in the
repo. I haven't done a completely thorough search, though, so I just wanted
to lean on some institutional knowledge if I can. If most of it is now
abandoned in favor of the Fedora builds and packages, then that would be a
huge relief.

--Greg

On Fri, Apr 24, 2020 at 3:09 PM Dominique Corbex 
wrote:

> On Fri, 24 Apr 2020 14:31:19 -0400
> Karl Kleinpaste  wrote:
>
> > Apr 24 10:51:44 godiva.kleinpaste.org systemd[6546]: Started libcrun
> > container.
> > *Apr 24 10:51:44 godiva.kleinpaste.org conmon[2268009]: conmon
> > f6d89ebf5dda38d47726 : Failed to create container: exit status 1*
>
> We don't have any more information to deal with...
>
> Maybe try to run podman directly, like:
>
> $ podman run -it fedora:latest echo Hello-World
> Trying to pull registry.fedoraproject.org/fedora:latest...
> Getting image source signatures
> Copying blob 00c5bb959822 done
> Copying config 8c2e0da7c4 done
> Writing manifest to image destination
> Storing signatures
> Hello-World
> $
>
> --
> domcox 
>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] Windows build: successful

[Greg Hellings]

On Sat, Apr 25, 2020 at 3:13 PM Karl Kleinpaste  wrote:

> I wanted to post something outside the previous thread on building for
> Windows, in case folks had started ignoring that one.
>
> Boy, ya mention a problem in need of attention, ya get some folks
> motivated, and stuff just happens.
>
> *HUGE THANKS to Dom and Greg* for their efforts. I thought I was in for a
> lot of grief and pain, trying to finish resurrecting the Windows build. But
> as of the most recent merge, we have a fully-automated Xiphos build for
> win32/64, driven by a Fedora30 container. All you need is to have podman
> installed, plus a directory containing xiphos and biblesync source
> directories, from which you issue this command (courtesy of Dom).
>
> podman run -it -v .:/source fedora:30
> /source/xiphos/win32/xc-xiphos-win.sh -win32 -win64 -b=/source/biblesync
>

Worth noting that this also works with Docker. Literally just replace the
"podman" with "docker" in the above command and the results are identical.
That's how builds are being done automatically upstream, so we know it
works, too.

The same script should be usable by anyone on a Fedora 30 machine/vm as
well. I know Windows people are much more likely to have access to VMs than
to Docker/Podman container environments so, with the same conditions as
Karl mentions (a vm with Xiphos and Biblesync source checked out), call the
xiphos/win32/xc-xiphos-win.sh script with the path to biblesync source
updated appropriately.


> It literally doesn't get easier than a single command to go from bare
> source tree to completely constructed installers. You can add "--rm" after
> "run" if you want to dispose of the container afterward.
>
> At the moment, Xiphos is ahead of Sword in terms of certain features, one
> of which will cause you annoyance in Bibles with pre-book and -chapter
> material, including ESV (if you still have it) and NASB. If you want to do
> any experimenting and building, you should locally revert this change in
> your tree prior to building:
>
> https://github.com/crosswire/xiphos/commit/74c88b94dc840d2e72d6a4ac974c0b3c56c42647.diff
> If you're building for Linux, then you should build your own Sword, the
> latest of which has the update addressed by this change and you don't need
> to revert.
>
> I haven't yet actually taken the result to a Windows machine, but under
> Wine it operates just fine as it always has.
>

If anyone out there has a Windows machine but doesn't have the ability to
build it themselves, the benefit of having the builds be automated is that
you can get the build artifacts from the CI builds.

1) Go to this URL: https://github.com/crosswire/xiphos/actions
2) Click on the build you want to test there (if you're looking to test
someone's latest PR or other request)
3) Click on the link under artifacts called "packages"
4) Open the zip file and choose the installer you want to test

"Nightly" (e.g. per commit) builds of RPMs are coming in the near future,
as well.

--Greg

> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] getting a new release out

[Greg Hellings]

On Sat, Apr 25, 2020 at 3:50 PM Karl Kleinpaste  wrote:

> It's been over 2 years since 4.1.0. Obviously, that's way too long. This
> is my fault, of course.
>
> In this time, we've gotten a new build system, and there's been a slew of
> bug fixes. Nothing new and huge, architecturally speaking, the way that
> (say) av11n kicked us up to v4, for example. So what needs to go out is
> 4.1.1. I have thoughts about bigger things that need to be done afterward
> (notably, the editor; and Abbrev needs a serious re-work) that might lead
> to enough change to justify calling it 4.2.
>
> From today's state of things, what needs to be done before we can put out
> 4.1.1?
>
> - For any Xiphos release prior to the next Sword release, ours needs to
> include the intro material revert .diff.
>

If you can mutter the proper svn command to me or post the actual diff file
here, I can get that added to both MinGW and native Fedora packages. Other
packagers might appreciate it, too

- There may be some peculiar machinations around Windows build due to that
> diff, the current state of other mingw packages (BibleSync needs to be
> built with Xiphos right now), and maybe Greg knows of other things.
>

I know of thing else regarding Windows that *needs* to happen

- I need to understand how the version stamp thing happens, now that
> Caleb's source_version.txt is in play. We simply tag just prior to doing
> github release?
>

I'm working on fully automating that, so all you have to do is tag the
commit in the repo and it will do all the releasing for you. Look for a PR
in the next few days to handle that. Once that's done a release will be as
simple as:

git tag v4.1.1
git push --tag

--Greg

>
> Anything else? Any reason we couldn't let 4.1.1 out the door before week's
> end?
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] getting a new release out

[Greg Hellings]

On Sat, Apr 25, 2020 at 5:43 PM Karl Kleinpaste  wrote:

> On 4/25/20 4:55 PM, Greg Hellings wrote:
>
> If you can mutter the proper svn command
>
>
> I was thinking of downgrading xiphos/src/main/display.cc during build to
> undo the fix I did. But if you want to incorporate Troy's fix from Sword,
> then you can get it with "svn diff -r3718:3721". Those are the Apr 18
> commits.
>

Builds for F30-F32 and Rawhide are on their way to updates-testing, so
that's going to be taken care of very shortly. We can do an update to the
build scripts to ensure we get that version of mingw-sword when it lands.

--Greg

> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] getting a new release out

[Greg Hellings]

On Sun, Apr 26, 2020 at 2:33 AM Caleb Maclennan  wrote:

> On Sat, Apr 25, 2020 at 11:50 PM Karl Kleinpaste 
> wrote:
> > - I need to understand how the version stamp thing happens, now that
> Caleb's source_version.txt is in play. We simply tag just prior to doing
> github release?
>
> Yes, just simply tag, then build. There should be virtually nothing to do.
>
> In fact it's kind of important you don't do anything else. If you tag
> a commit as, say, "v4.2.0", then realize you forgot something and
> commit a small change, then build, what you build won't be v4.2.0 at
> all it will be v4.2.0.1. In other words to get the actual release
> version as tagged you _must_ build from the actual tagged commit. You
> can't fudge and actually build something else and just call it
> something its not.
>

We aren't quite there, yet. I have CI passing all builds and creating the
Windows artifacts, but I don't yet have it creating the final build
artifacts for publishing *quite* yet. Not because there's anything wrong,
just because my daughter is back with me this week (she comes and goes
every other week to her mom's) and with her home for school I'll be
focusing on that this week. So I may or may not get to finish release
processing between $dayjob and $dadjob


> By the way I would be inclined to make the next release v4.2.0 not
> v4.1.1. If you actually follow SemVer there are a lot more changes
> than should fit in only a patch version bump. As a distro packager I
> expect patch versions to build and install virtually identically to
> previous versions. This release will require an entirely new set of
> build commands, and even the dependencies have changed. Even if there
> is not a much in the way of user facing changes the under-the-hood
> stuff is radically different and shouldn't be hidden behind a patch
> release number bump — at least not in my opinion as a downstream
> packager.
>

I would agree with this sentiment. Fedora is a bit loosey-goosey with what
it allows in, but you're not going to slip this past other distros as a
patch release. It really isn't, especially once we tossed in the change
from libgsf to minizip. Let's just cut loose the next version as 4.2.0 and
maybe take the extra few weeks to figure out editor/HTML needs. At least a
roadmap even if we don't finish them in time to make 4.2.0, we can have
4.3.0 well on its way.

--Greg

>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] getting a new release out

[Greg Hellings]

On Sun, Apr 26, 2020, 02:55 Caleb Maclennan  wrote:

> On Sun, Apr 26, 2020 at 10:39 AM Greg Hellings 
> wrote:
> > We aren't quite there, yet.
>
> Sure we are. But I think we might be talking about different things.
> My comments were all about local tagging and builds. That part should
> be 100% working now, or my job on that PR isn't done. You should be
> able to tag locally, then build and get the right release version.
> This can be tested just by `git tag`, then build and run it and see
> what version it says it is. `make -C build source_package` should also
> have the right filename. (Be sure to delete any such test tags before
> pushing!)
>
> What you are talking about is automating the builds on Github when a
> tag is pushed to the remote repository so there is no local build step
> needed. Great work on that and sorry I havn't been more help by the
> way. That's the part you mean is not quite there yet, correct?
>

Correct. Currently he can tag and do build, then upload. I'm very close to
getting the release process down to tag, push tag, relax with family while
GA does builds and uploads.


> > I have CI passing all builds and creating the Windows artifacts, but I
> don't yet have it creating the final build artifacts for publishing *quite*
> yet.
>
> I haven't looked at your code yet, but I assume you are building and
> posting artifacts on all [push, pull_request] jobs, but filtering `on:
> push: tags: [ "v*" ]` and running an extra job on them to post the
> correct artifacts to a Github release matching the tag ... correct? Or
> at least that's the goal, no?
>

That is the goal. Currently I have Windows artifacts building and stashing
on every commit or tag. I also have Linux builds completing.

All that remains is adding the Linux artifact stashing and releasing on tag
events. That's just a matter of about four more steps in Github, but I got
distracted by sleep, which I'm about to do again. 😂


> > I would agree with this sentiment. Fedora is a bit loosey-goosey with
> what it allows in, but you're not going to slip this past other distros as
> a patch release. It really isn't, especially once we tossed in the change
> from libgsf to minizip. Let's just cut loose the next version as 4.2.0 and
> maybe take the extra few weeks to figure out editor/HTML needs. At least a
> roadmap even if we don't finish them in time to make 4.2.0, we can have
> 4.3.0 well on its way.
>
> I definitely don't want to hold up the release any longer than it
> needs to be and I'm not advocating for stuffing new features in to
> make it worthy of a minor version number bump, all I'm saying is that
> it already needs at least a minor version bump with what's in the
> release so far. The editor can go in 4.3. I wouldn't put anything else
> on the roadmap for 4.2 other than getting the build and release
> process ironed out.
>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

[xiphos-devel] GConf2, mingw-biblesync package news/questions

[Greg Hellings]

I'm getting caught up on messages and tasks over the weekend related to
Fedora packages and two quick things:

1) I got a mingw-biblesync package approved for Fedora, including the f30
branch. Builds are happening now, and that will appear in the
updates-testing and eventually updates repo in short order. Once it does,
I'll update CI to pull the package rather than require a checkout of
Biblesync code to build.

2) Does our display toolkit still rely on GConf2? Have we or are we going
to replace it? It's still listed as a build dependency in my package spec,
but the package has recently been orphaned in Fedora and is in danger of
being auto-removed if no one picks it up. If it's still important to us,
I'll pick it up to be sure we don't lose it, but if we have replaced it
(and I just haven't updated the deps) I'll let it go.

--Greg
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] GConf2, mingw-biblesync package news/questions

[Greg Hellings]

On Mon, Apr 27, 2020 at 12:33 PM Karl Kleinpaste 
wrote:

> On 4/27/20 11:54 AM, Greg Hellings wrote:
>
> Does our display toolkit still rely on GConf2?
>
> https://github.com/crosswire/xiphos/issues/918
> closed by you. :-)
>

Ah, auto-closed when I merged that branch. I thought there had been
discussion about eliminating gconf dependencies. That will reduce our
dependency matrix nicely in the next release of Xiphos, as well.

--Greg

>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] release this weekend?

[Greg Hellings]

I know of nothing to hinder us.

1) Yes, that PR is ready to go
2) I just added a second PR to move us to using the pre-built Fedora
MinGW-Biblesync package

Making a release, after the PR is in, from your local system is:
# Only if you're not on the HEAD of master locally
git co master
git pull
# actual release
git tag 4.2.0
git push origin 4.2.0

After the build is done, if you want to go in and edit release notes, etc,
you're welcome to do that. But the automation will build *.exe, *.rpm,
*.deb, *.tar.{gz,xz}, create the release, and add all those to the release
commit. After that, you can add release information if you'd like.

--Greg

On Fri, May 1, 2020 at 7:51 AM Karl Kleinpaste  wrote:

> Is there anything to stop us from letting 4.2.0 out the door this weekend?
> I need to update a new top section in RELEASE-NOTES, of course.
> Greg, is that PR ready to go?
>
> What exactly is involved now in "making a release," from the standpoint of
> all the new automated tag and build processes? Previously (waf etc), I
> would edit a version stamp into several files, the commit of that would
> become the released version, and I'd include tarball and Windows *.exe in
> the releases page. Now, I'm thinking that we mostly tag the relevant commit
> and let some of the new automated machinery do its thing. Details, please,
> for the sake of all concerned.
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] 4.2.0 tagged and pushed

[Greg Hellings]

On Sat, May 2, 2020 at 9:55 AM Karl Kleinpaste  wrote:

> On 5/2/20 10:40 AM, Karl Kleinpaste wrote:
>
> What's where, now that tag/push is done?
>
>
> OK, to follow up to myself, I got the auto-build results email, which
> reports 6 successful builds and 1 failed deployment.  From that email, I
> used the link to see the results, and have a packages.zip (174M) containing
> 2 Windows *.exe, 1 Fedora 31 rpm, a generic tarball (funny name, has double
> '.'), and a deb, which I presume is generic to Debian and Ubuntu both
> (editor-less?).  No Arch build?  I'm guessing that I should create a new
> release using these as the assets to be uploaded.  Or is there a way to
> auto-import them?  Should we bother including rpm and deb files,
> considering such systems should pick them up automatically from their
> overall update framework?
>

Answering each thing separately:

* Distro files:
* The deb file is specifically generated as part of the Ubuntu
workflow, but it's going to require a bit of manual install of deps,
because that's not packaged into the file. Also no - it's not editor-less,
and it would require packaging up the GtkHTML we're building from source
inside of the
* RPM is specific to the version of Fedora it was built on, as well.
* Conclusion: we can probably drop both of these as release artifacts.
Let distros do their own packaging that way it's properly integrated. If we
want to offer our own package repositories, we should do so by offering
proper repos that can be added to apt/yum/zypper/pacman etc rather than
one-off download files.
* double '.' is something we need to look into in the CMake sources. I'll
open an issue for that. I thought I had seen it, but chalked it up to my
eyes must be going bad
* I'm not sure Arch builds are a thing? I'm really hazy on how Arch works.
It seems like the modern day Gentoo, but with a better wiki.
* All of those assets *should* have been uploaded automatically. However,
the release script appears to have choked on itself in the place I least
would have expected it to do so ("cd packages"), thus leading to the
release not being created from the tag. I'm looking into this as we type.
For now, you can either choose to upload the assets you want, manually, or
we can wait for me to figure out What Is Going On (TM) with the release.
All that I'm doing inside of that "packages" folder is making a .tar.xz out
of the .tar.gz so that both formats are uploaded.

--Greg

> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] 4.2.0 tagged and pushed

[Greg Hellings]

On Sat, May 2, 2020 at 1:03 PM Karl Kleinpaste  wrote:

> Just noticed, we have a Windows build problem.  I just installed the
> win64.exe, result doesn't run, packaging problem.
>
> env WINEPREFIX="/home/karl/.wine" wine C:\\windows\\command\\start.exe
> /Unix /home/karl/.wine/dosdevices/c:/ProgramData/Microsoft/Windows/Start\
> Menu/Programs/Xiphos/Xiphos.lnk
> 01b8:err:winediag:xrandr12_init_modes Broken NVIDIA RandR detected,
> falling back to RandR 1.0. Please consider using the Nouveau driver instead.
> 01b8:fixme:exec:SHELL_execute flags ignored: 0x0100
> 01b8:fixme:exec:SHELL_execute flags ignored: 0x4100
> *01ba:err:module:import_dll Library libbiblesync.dll (which is needed by
> L"C:\\Program Files\\Crosswire\\Xiphos\\bin\\xiphos.exe") not found*
> 01ba:err:module:LdrInitializeThunk Importing dlls for L"C:\\Program
> Files\\Crosswire\\Xiphos\\bin\\xiphos.exe" failed, status c135
>
> Does it need to be packaged from a different source now?
>

Yes, it does. It now will live in the sys bin dir instead of parallel (the
other branch of the conditional checks in the sys lib dir, which is also
not quite right). Including that in my patch.

--Greg

>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] 4.2.0 tagged and pushed

[Greg Hellings]

I'm good with it. Typically things pushed publicly you're discouraged from
modifying, but I see no issues in this case.

--Greg

On Sat, May 2, 2020 at 1:18 PM Karl Kleinpaste  wrote:

> On 5/2/20 2:16 PM, Greg Hellings wrote:
>
> Including that in my patch.
>
> I see that git supports deleting a tag.  (Never noticed that before.)  Are
> we good with doing git tag -d 4.2.0, merging a patch, and re-tagging?
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] 4.2.0 tagged and pushed

[Greg Hellings]

On Sat, May 2, 2020 at 3:50 PM Karl Kleinpaste  wrote:

> On 5/2/20 4:10 PM, Caleb Maclennan wrote:
>
> If you are deleting the tag, DO IT NOW.
>
>
> At this point, we'll just let 4.2.0 go, and tag 4.2.1 for a real release
> once Greg does his patch.
>

Just want to update on this:

1) I fell off the bandwagon this weekend and got sucked into a video game.
Totally forgot to come up for air and take care of my commitments. My
apologies.

2) The problem with the release arose because I didn't pin the version of
the release actions we were using in Github Actions. I specified to use
@master instead of @v1 for the upload/download artifact steps. Between when
I pushed my version and when Karl made the release v2 of it was released,
and it changed the directory structure of how the artifacts are downloaded.
That's what caused the break in 4.2.0 release. I've resolved this portion
now.

Additional things I'm cleaning up in the release process, since I'm in
there with my monkey wrench:
3) Not generating RPM and DEB files any longer. This is just going to be
fraught with trouble, as downstream distros contain lots of conditionals
and building criteria. Also, because on the Deb architectures we're
building against libraries that aren't packed by upstream any longer. So
there's no reason to release a deb file that simply can't be installed any
longer.

4) The mingw-biblesync packages are now in stable form in the Fedora
repositories, and they squeaked in just under the wire for inclusion in
Fedora 30 (that goes EOL this month, so we cut it pretty close on that). So
I've updated the Windows build process to no longer build that from source,
but rather to install the pre-built binaries. It's such a small library
that this isn't really any, or much, of a time saver in the builds, but
it's unnecessary steps, so we can now skip that step.

5) I've moved the dnf install steps of the Windows build into a Dockerfile.
For the purposes of release and CI, this doesn't really change anything,
because we want to make sure that Dockerfile is up to date. However, from a
developer's perspective it can change a whole lot. Instructions are
included, but now you can run the "docker/podman build -t xiphos_win"
command one time and it will create a container image with all the
dependency packages already installed and it already will know where to
look for the cross-compile shell script to run it. From then on, to create
a Windows build, all you need to do is execute "docker/podman run -it -v
path/to/xiphos:/source xiphos_win" and pass it the arguments for the shell
script. It will no longer need to download repository metadata or packages
every time you want to test a build. It will still do a clean configure and
build from scratch, but unless you're editing the Dockerfile itself (e.g.
changing the dependency packages), there will be no need to re-run the
container build on subsequent steps. For those of us on limited or slow
bandwidth this is a huge gain, and it's probably a significant gain for
most everyone.

6) I've discovered the source of the spurious "." in the source files. It
comes when you do a "cpack -G TGZ" instead of "make package_source". CPack
should not be used to generate the source directly, as it turns out.

A few last bits and pieces to clean up in the release and I'll have that PR
up. Hopefully tonight.

--Greg

>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] 4.2.0 tagged and pushed

[Greg Hellings]

On Fri, May 8, 2020 at 6:08 AM Caleb Maclennan  wrote:

> And before anybody chimes in, yes I'm aware there are yet more namespaces
> already floating around on launchpad. There is a "crosswire-misc" project,
> a "~pkg-crosswire-devel" team, and half a dozen "xiphos-something" projects
> users have spawned building their own PPAs. I would ignore all the bits
> except the ones I mentioned before and gradually hope to
> cleanup/consolidate/obsolete them in favor of clearly named canonical
> namespaces for the various resources.
>
> I also forgot to mention my third recommendation: the least disruptive
> solution(s) possible are to use the existing "xiphos-devel" or
> "pkgcrosswire" team team space and add a new PPA (either "xiphos-devel/ppa"
> or "pkgcrosswire/xiphos" and setup packaging there. No renames to existing
> launchpad stuff, just a new new fresh PPA and leave the existing archaic
> Crosswire PPAs to be cleaned up later.
>

I would say don't re-invent the wheel, and don't try to rename it to "round
rolly thing", either. Use pkgcrosswire, as ugly as that might be to us. It
has history, I believe it's where packages have long been held. Follow the
KISS principle.

--Greg
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] 4.2.0 tagged and pushed

[Greg Hellings]

On Fri, May 8, 2020 at 4:33 PM Caleb Maclennan  wrote:

> On Sat, May 9, 2020 at 12:20 AM Greg Hellings 
> wrote:
>
>> Use pkgcrosswire, as ugly as that might be to us. It has history, I
>> believe it's where packages have long been held.
>>
>
> Thanks for the input Greg.
>
> Can you clarify whether you would suggest stuffing new packages into the
> existing ppa:pkgcrosswire/ppa namespace alongside the obsolete stuff or
> adding a clean PPA just for Xiphos and its direct dependencies such as
> ppa:pkgcrosswire/xiphos?
>

I would stick with just updating the existing ones. It shouldn't be hard to
drop in a new Sword, BibleTime, and Xiphos (I assume those are the three
packages in the PPA?)

--Greg

>
> I can definitely pursue that direction, although at the moment I wasn't
> actually given enough permissions to go either of those two routes.
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] 4.2.0 tagged and pushed

[Greg Hellings]

On Fri, May 8, 2020 at 6:20 PM Caleb Maclennan  wrote:

> On Sat, May 9, 2020 at 2:02 AM Karl Kleinpaste 
> wrote:
>
>> If any of it has modtimes longer than maybe 6 months ago, it's too old to
>> be interesting or worthwhile.
>>
>
> The range is 2009-2012.
>
> That's a wee bit longer than 6 months ago unless my brain is having a hard
> time with math at 2 am.
>
> Maybe Greg can comment to this better than I can, but I believe all the
> packages in a PPA have tags for which version of Ubuntu they are targeting
> and that if people add this existing PPA to a machine updated in the last
> decade they won't even see any of these packages. Is that right? This stuff
> is all targeting 8.04 through 12.04.
>

I believe so. It's like in Fedora and probably most other versioned distros
- copies of files for each distro are typically contained within
directories named for it so you can have a path to the repo base and then
just tell it "go to $version/$arch/$release_stream" or whatever. I left the
Ubuntu/Debian world probably back around 2012 because their packaging
system (not the repos, per say, but the actual packaging directory you need
to keep) is an absolute nightmare and the tooling at the time was
attrocious compared to RPM building which took only a spec file to get done.

Every time I've looked again to see if it's gotten better, it hasn't. So I
moved to Fedora and I've loved everything about it - from the ease of
package maintenance to the much more friendly and welcoming user and
developer environment.


> The package list in question is here:
> https://launchpad.net/~pkgcrosswire/+archive/ubuntu/ppa
>
> I don't currently have access to nuke individual packages (although oddly
> enough it looks like I could drop the whole PPA). I think I can freshen up
> the Sword & Xiphos targeting 20.04 and I guess add BibleSync and GTKHTML.
>

Agreed with Karl - either nuke it, or just add packages for the new
versions and ignore what came before. All those old packages are worthless
these days. Even 16.04 is nearing end of life, so 12.04 and earlier are
worthless to even look at updating.

Burn it all with fire.

--Greg

> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] why produce tar files?

[Greg Hellings]

On Mon, May 11, 2020 at 1:23 AM Caleb Maclennan  wrote:

> Because the Git generated archive of the raw repository contents is not
> the same contents as the generated source packages. Specifically the former
> has no information about what version it is. The two ways to get this
> information are to have git history (i.e. you can use a clone of the
> repository to build) or to have a source build that has this generated
> information present (i.e. our generated version specific tarballs that have
> the relevant information cached inside).
>

I do want to say: it's a bit of a nuisance to do testing this way, though.
In order to generate a source tar, I have to successfully run CMake against
the tree, which means I need all the devel dependencies installed on my
machine. It's not impossible, but it is a bit of a pain. I'm all in favor
of the CPack generators for Windows installers, but it's not terribly
convenient for the source tar generation.

--Greg

>
>
> On Sun, May 10, 2020 at 5:41 PM Karl Kleinpaste 
> wrote:
>
>> github release process automatically produces tarfiles, zip and tar.gz.
>> Yet our release machinery also produces tarfiles, tar.gz and tar.xz.
>> Why?
>> ___
>> xiphos-devel mailing list
>> xiphos-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] windows script can't find cmake?

[Greg Hellings]

Have you executed the podman build step, per the new docs? The install is
all done during the build step and saved as an image so you don't have to
go through that download and install of the deps on every build.

For me it cuts the build time from about ten minutes to one minute, but
without the build step you'll be missing the needed commands.

On Sun, May 17, 2020, 07:05 Karl Kleinpaste  wrote:

> I've built before for Windows using podman and had no trouble.  Today it
> can't find cmake:
>
> + echo '** Building Xiphos for Windows-64 bit:'
> ** Building Xiphos for Windows-64 bit:
> + do_build 64
> + bits=64
> + mkdir -p win64
> + cd win64
> + cmake -DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-mingw64.cmake
> -DGTK2=ON /source/xiphos
> */source/xiphos/win32/xc-xiphos-win.sh: line 84: cmake: command not found*
>
> I wondered if recent changes to how the container is managed had some bad
> effect, so I wiped out ~/.local/share/containers to start fresh and tried
> again; same result.
>
> I'm trying to do a console-enabled build for someone having trouble on his
> Win64 machine.  Any wisdom available?
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] windows script can't find cmake?

[Greg Hellings]

On Sun, May 17, 2020 at 2:15 PM Karl Kleinpaste  wrote:

> On 5/17/20 12:08 PM, Greg Hellings wrote:
>
> Have you executed the podman build step, per the new docs?
>
>
> $ grep -rl podman
> win32/WindowsBuildNotes.txt
>

$ grep docker win32/WindowsBuildNotes.txt
docker run --rm -it -v $(pwd):/source greg-hellings/xiphos
docker build -t xiphos win32
docker run --rm -it -v $(pwd):/source xiphos

The first line is what "will be possible" after I add auto-building of the
source container image. The middle line is the line you're missing. That
will "build" the container based on the Dockerfile in win32/ and "-t
xiphos" will "tag" the resulting built image as "xiphos" on your local
system. That's a command you only need to run once (or if we ever edit the
Dockerfile in the future, but we probably won't do that until we update to
GTK3 and a new editor/display solution for Windows). The second command is
what you'll run as often as you need to test the Windows compile.

You should notice that the "run" command is much faster now, as all the
download and install is part of that "build" step instead of being crammed
into the shell script.

--Greg

> $
>
> Not much ref to podman there.
>
> Attempting "podman run --rm -it -v $(pwd):/source xiphos" (per that file)
> was ... verbosely unsuccessful.
>
> What am I missing?
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] windows script can't find cmake?

[Greg Hellings]

On Sun, May 17, 2020 at 10:39 PM Greg Hellings 
wrote:

>
>
> On Sun, May 17, 2020 at 2:15 PM Karl Kleinpaste 
> wrote:
>
>> On 5/17/20 12:08 PM, Greg Hellings wrote:
>>
>> Have you executed the podman build step, per the new docs?
>>
>>
>> $ grep -rl podman
>> win32/WindowsBuildNotes.txt
>>
>
> $ grep docker win32/WindowsBuildNotes.txt
> docker run --rm -it -v $(pwd):/source greg-hellings/xiphos
> docker build -t xiphos win32
> docker run --rm -it -v $(pwd):/source xiphos
>

Caveat lector: use "podman" instead of "docker" for these, if you're on a
system that's Fedora >= 31 or CentOS/RHEL 8 as Docker isn't really
supported on those systems. The rest of the command is identical in all
cases.

--Greg

>
> The first line is what "will be possible" after I add auto-building of the
> source container image. The middle line is the line you're missing. That
> will "build" the container based on the Dockerfile in win32/ and "-t
> xiphos" will "tag" the resulting built image as "xiphos" on your local
> system. That's a command you only need to run once (or if we ever edit the
> Dockerfile in the future, but we probably won't do that until we update to
> GTK3 and a new editor/display solution for Windows). The second command is
> what you'll run as often as you need to test the Windows compile.
>
> You should notice that the "run" command is much faster now, as all the
> download and install is part of that "build" step instead of being crammed
> into the shell script.
>
> --Greg
>
>> $
>>
>> Not much ref to podman there.
>>
>> Attempting "podman run --rm -it -v $(pwd):/source xiphos" (per that
>> file) was ... verbosely unsuccessful.
>>
>> What am I missing?
>> ___
>> xiphos-devel mailing list
>> xiphos-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>>
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] windows script can't find cmake?

[Greg Hellings]

On Mon, May 18, 2020 at 4:24 AM Karl Kleinpaste  wrote:

> On 5/17/20 11:39 PM, Greg Hellings wrote:
>
> $ grep docker win32/WindowsBuildNotes.txt
> docker run --rm -it -v $(pwd):/source greg-hellings/xiphos
> docker build -t xiphos win32
> docker run --rm -it -v $(pwd):/source xiphos
>
>
> $ podman run --rm -it -v $(pwd):/source greg-hellings/xiphos
> Trying to pull registry.fedoraproject.org/greg-hellings/xiphos...
>   manifest unknown: manifest unknown
> Trying to pull registry.access.redhat.com/greg-hellings/xiphos...
>   name unknown: Repo not found
> Trying to pull registry.centos.org/greg-hellings/xiphos...
>   manifest unknown: manifest unknown
> Trying to pull docker.io/greg-hellings/xiphos...
> *  denied: requested access to the resource is denied*
> Error: unable to pull greg-hellings/xiphos: 4 errors occurred:
> * Error initializing source docker://
> registry.fedoraproject.org/greg-hellings/xiphos:latest: Error reading
> manifest latest in registry.fedoraproject.org/greg-hellings/xiphos:
> manifest unknown: manifest unknown
>     * Error initializing source docker://
> registry.access.redhat.com/greg-hellings/xiphos:latest: Error reading
> manifest latest in registry.access.redhat.com/greg-hellings/xiphos: name
> unknown: Repo not found
> * Error initializing source docker://
> registry.centos.org/greg-hellings/xiphos:latest: Error reading manifest
> latest in registry.centos.org/greg-hellings/xiphos: manifest unknown:
> manifest unknown
> * Error initializing source docker://greg-hellings/xiphos:latest:
> Error reading manifest latest in docker.io/greg-hellings/xiphos: errors:
> *denied: requested access to the resource is denied*
> unauthorized: authentication required
>
> Honestly, I am not trying to be a pain your backside.
>

"The first line is what "will be possible" after I add auto-building of the
source container image. The middle line is the line you're missing." is
what I said in the previous email. :P

Adding that auto-build now.

--Greg

>
> It's just a gift...
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] windows script can't find cmake?

[Greg Hellings]

On Mon, May 18, 2020 at 11:14 AM Greg Hellings 
wrote:

>
>
> On Mon, May 18, 2020 at 4:24 AM Karl Kleinpaste 
> wrote:
>
>> On 5/17/20 11:39 PM, Greg Hellings wrote:
>>
>> $ grep docker win32/WindowsBuildNotes.txt
>> docker run --rm -it -v $(pwd):/source greg-hellings/xiphos
>> docker build -t xiphos win32
>> docker run --rm -it -v $(pwd):/source xiphos
>>
>>
>> $ podman run --rm -it -v $(pwd):/source greg-hellings/xiphos
>> Trying to pull registry.fedoraproject.org/greg-hellings/xiphos...
>>   manifest unknown: manifest unknown
>> Trying to pull registry.access.redhat.com/greg-hellings/xiphos...
>>   name unknown: Repo not found
>> Trying to pull registry.centos.org/greg-hellings/xiphos...
>>   manifest unknown: manifest unknown
>> Trying to pull docker.io/greg-hellings/xiphos...
>> *  denied: requested access to the resource is denied*
>> Error: unable to pull greg-hellings/xiphos: 4 errors occurred:
>> * Error initializing source docker://
>> registry.fedoraproject.org/greg-hellings/xiphos:latest: Error reading
>> manifest latest in registry.fedoraproject.org/greg-hellings/xiphos:
>> manifest unknown: manifest unknown
>> * Error initializing source docker://
>> registry.access.redhat.com/greg-hellings/xiphos:latest: Error reading
>> manifest latest in registry.access.redhat.com/greg-hellings/xiphos: name
>> unknown: Repo not found
>> * Error initializing source docker://
>> registry.centos.org/greg-hellings/xiphos:latest: Error reading manifest
>> latest in registry.centos.org/greg-hellings/xiphos: manifest unknown:
>> manifest unknown
>> * Error initializing source docker://greg-hellings/xiphos:latest:
>> Error reading manifest latest in docker.io/greg-hellings/xiphos: errors:
>> *denied: requested access to the resource is denied*
>> unauthorized: authentication required
>>
>> Honestly, I am not trying to be a pain your backside.
>>
>
> "The first line is what "will be possible" after I add auto-building of
> the source container image. The middle line is the line you're missing." is
> what I said in the previous email. :P
>

Or, as the WindowsBuildNotes.txt explains:

"If you don't want to use the greg-hellings/xiphos image or it is
unavailable
for some reason, you can build the image yourself locally, first, like
this:"

--Greg

>
> Adding that auto-build now.
>
> --Greg
>
>>
>> It's just a gift...
>> ___
>> xiphos-devel mailing list
>> xiphos-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>>
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] windows script can't find cmake?

[Greg Hellings]

Just a note: I added the build to Docker hub and it's now up. You don't
have to initiate the build locally anymore. You can just use the first
command and build with my image:
https://hub.docker.com/repository/docker/greghellings/xiphos/general

--Greg

On Mon, May 18, 2020 at 11:15 AM Greg Hellings 
wrote:

>
>
> On Mon, May 18, 2020 at 11:14 AM Greg Hellings 
> wrote:
>
>>
>>
>> On Mon, May 18, 2020 at 4:24 AM Karl Kleinpaste 
>> wrote:
>>
>>> On 5/17/20 11:39 PM, Greg Hellings wrote:
>>>
>>> $ grep docker win32/WindowsBuildNotes.txt
>>> docker run --rm -it -v $(pwd):/source greg-hellings/xiphos
>>> docker build -t xiphos win32
>>> docker run --rm -it -v $(pwd):/source xiphos
>>>
>>>
>>> $ podman run --rm -it -v $(pwd):/source greg-hellings/xiphos
>>> Trying to pull registry.fedoraproject.org/greg-hellings/xiphos...
>>>   manifest unknown: manifest unknown
>>> Trying to pull registry.access.redhat.com/greg-hellings/xiphos...
>>>   name unknown: Repo not found
>>> Trying to pull registry.centos.org/greg-hellings/xiphos...
>>>   manifest unknown: manifest unknown
>>> Trying to pull docker.io/greg-hellings/xiphos...
>>> *  denied: requested access to the resource is denied*
>>> Error: unable to pull greg-hellings/xiphos: 4 errors occurred:
>>> * Error initializing source docker://
>>> registry.fedoraproject.org/greg-hellings/xiphos:latest: Error reading
>>> manifest latest in registry.fedoraproject.org/greg-hellings/xiphos:
>>> manifest unknown: manifest unknown
>>> * Error initializing source docker://
>>> registry.access.redhat.com/greg-hellings/xiphos:latest: Error reading
>>> manifest latest in registry.access.redhat.com/greg-hellings/xiphos:
>>> name unknown: Repo not found
>>> * Error initializing source docker://
>>> registry.centos.org/greg-hellings/xiphos:latest: Error reading manifest
>>> latest in registry.centos.org/greg-hellings/xiphos: manifest unknown:
>>> manifest unknown
>>> * Error initializing source docker://greg-hellings/xiphos:latest:
>>> Error reading manifest latest in docker.io/greg-hellings/xiphos: errors:
>>> *denied: requested access to the resource is denied*
>>> unauthorized: authentication required
>>>
>>> Honestly, I am not trying to be a pain your backside.
>>>
>>
>> "The first line is what "will be possible" after I add auto-building of
>> the source container image. The middle line is the line you're missing." is
>> what I said in the previous email. :P
>>
>
> Or, as the WindowsBuildNotes.txt explains:
>
> "If you don't want to use the greg-hellings/xiphos image or it is
> unavailable
> for some reason, you can build the image yourself locally, first, like
> this:"
>
> --Greg
>
>>
>> Adding that auto-build now.
>>
>> --Greg
>>
>>>
>>> It's just a gift...
>>> ___
>>> xiphos-devel mailing list
>>> xiphos-devel@crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>>>
>>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] "make clean" removes po/*.po

[Greg Hellings]

Interesting - CMake thinks that this is a generated file. If it is
generated then "make clean" should properly clean it out. But it's also
trying to open "ar.po" in order to clean "ar.po". Which doesn't make much
sense.

I don't know how .po files work. Are they generated?

--Greg

On Fri, Sep 11, 2020 at 8:25 AM Karl Kleinpaste  wrote:

> cmake -DBUILD_SHARED_LIBS=TRUE -DCMAKE_INSTALL_PREFIX=/usr
> -DLIBDIR=/usr/lib64 -DGTKHTML=ON -DDEBUG=ON
> -DCMAKE_BUILD_TYPE=RelWithDebInfo ../xiphos
> [ build dir is populated ]
>
> ls po
> [ *.po are present ]
>
> make clean
> ls po
> [ *.po are gone ]
>
> make
> ...
> [ 63%] Generating ar.po
> /usr/bin/msgmerge: error while opening
> "/home/karl/src/bible/xbuild/po/ar.po" for reading: No such file or
> directory
> make[2]: *** [po/CMakeFiles/potfiles_1.dir/build.make:272: po/ar.po] Error
> 1
> make[1]: *** [CMakeFiles/Makefile2:875: po/CMakeFiles/potfiles_1.dir/all]
> Error 2
> make: *** [Makefile:172: all] Error 2
>
> Thoughts? It seems to me that make clean should not be vacuuming out *.po.
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://crosswire.org/mailman/listinfo/xiphos-devel

[xiphos-devel] 1.9.0RC3 Windows builds

[Greg Hellings]

So we're back on the upgrade train for Sword this time.

But we can't make official Fedora 30 builds because the window for that
closed about a year ago. So I'm trying to update our build Dockerfile to
compile Sword 1.9.0 from source with the older libraries. But the old
version of gcc there gives an error with the 1.9.0 sources in my attempt to
cross compile for 64-bit targets. Then I get this error:

/usr/src/sword-1.9.0RC3/src/modules/common/rawstr4.cpp:116:21: error: cast
from 'sword::FileDesc*' to 'long unsigned i
nt' loses precision [-fpermissive]

   if ((unsigned long)datfd > 0) {

The builds run fine on modern Fedora, so it's not an issue with Sword
itself. It's the older version of gcc that's on Fedora 30. This leaves us a
"do we patch Sword" somehow, or do we finally bite the bullet and get off
GTK2/Fedora 30?

--Greg
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] 1.9.0RC3 Windows builds

[Greg Hellings]

I thought it was because of gtkHTML for the editor?

--Greg

On Mon, Oct 12, 2020, 08:14 Karl Kleinpaste  wrote:

> On 10/12/20 12:39 AM, Greg Hellings wrote:
>
> This leaves us a "do we patch Sword" somehow, or do we finally bite the
> bullet and get off GTK2/Fedora 30?
>
>
> Question is actually "Is there a working GTK3 we can use in Win32?"
> because that's why we do so.
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://crosswire.org/mailman/listinfo/xiphos-devel

Re: [xiphos-devel] failed builds after vietnamese translation added

[Greg Hellings]

OK so the Ubuntu one should be easy. It applies a few patches to SWORD.
Those can be dropped and we should upgrade to SWORD 1.9 anyway.

The Arch build? Sounds like an upstream bug or change. I thought we're
installing all those files from the AUR, and it looks like it's not
installing the BibleSync development files in the same place that we're
looking for it (or at all?). I don't know enough about Arch to know if
that's because they've pulled apart the package to library/devel like
Fedora and Ubuntu do, or not.

--Greg

On Mon, Jan 25, 2021 at 4:22 AM Karl Kleinpaste  wrote:

> We had a contribution of a new translation; it was such a simple and blunt
> change (add .po, tweak LINGUAS), I just did it directly without a branch.
>
> The auto-build processes were not happy, however. Fedora and Windows were
> fine (which is why I was confident in doing it directly, when I did a build
> of my own in F33), but Arch and Ubuntu failed.
>
> I expect Ubuntu to fail due to the editor issue, but it went somewhere
> else, and Arch failed for what seems stupid reasons.
>
> Somebody in these environments want to take a look?
>
> https://github.com/crosswire/xiphos/actions/runs/506489901
>
> Arch:
> CMake Error at
> /usr/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:218
> (message):
>   Could NOT find Biblesync (missing: BIBLESYNC_INCLUDE_DIR
>   BIBLESYNC_LIBRARY_DIR)
> Call Stack (most recent call first):
>   /usr/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:582
> (_FPHSA_FAILURE_MESSAGE)
>   cmake/modules/FindBiblesync.cmake:68 (find_package_handle_standard_args)
>   cmake/XiphosDependencies.cmake:51 (find_package)
>   CMakeLists.txt:88 (include)
> -- Configuring incomplete, errors occurred!
> See also "/rootdir/build/CMakeFiles/CMakeOutput.log".
> !!! ERROR: run command [docker exec -t xiphos-archlinux-build
> /rootdir/build_scripts].
> Error: Process completed with exit code 1.
>
> Ubuntu:
> 1703 + tar xf sword-1.8.1.tar.gz
> 1704 + cd sword-1.8.1
> 1705 + patch -p1 -i ../sword-1.8.1-cmake.diff
> 1706 patch unexpectedly ends in middle of line
> 1707 patch:  Only garbage was found in the patch input.
> 1708 !!! ERROR: run command [docker exec -t xiphos-ubuntu-build
> /rootdir/before_scripts].
> 1709 Error: Process completed with exit code 1.
>
> ___
> xiphos-devel mailing list
> xiphos-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/xiphos-devel
>
___
xiphos-devel mailing list
xiphos-devel@crosswire.org
http://crosswire.org/mailman/listinfo/xiphos-devel