Re: [sword-devel] I give up

[Israel Dahl]

On 5/13/20 4:57 PM, Tom Sullivan wrote:
> ...snip...
>
> Suggestion 1: Clean up documentation. Prime exhibit: May Crosswire
> page refers to Sword 1.8.0 with link for months with no mention of 1.8.1.
>
This is essential, and what makes it hard for new people to pick up and
work on some projects (not crosswire specific, but FLOSS in general)
> Suggestion 2: For the more popular distros, provide ready-to-go
> packages, .deb files (or equivalent, such as .rpm) for installs and
> updates, even if they do not hit the repositories until later. This
> will get users access who are not experts. In my opinion, for what it
> is worth, this is at least as important as new features. Also allow
> users an option to automatically check for updates and tell where to
> get a new package. I understand that this takes time and work. I would
> rather get some new features and bug fixes, and be able to get and use
> them, than new features I will never see because I can't compile or
> something. I rather think that others are also in my position as well.
>
I do think looking into a PPA (since it would be easier), and flatkpak/snap


From the sound of it you seem to have issues in the Debian packaging
format.  You can require specific versions of files in your
debian/control.  This will prevent new versions from building on older
systems, but containerized packages (flatpak/snap) would solve that
issue.  This is a reason I switched to a Rolling Release type distro. 
Technically you can do this in Ubuntu/Debian, and I have in the past

If you need help on packaging specifically for Debian/Ubuntu I'd be glad
to assist you!  Just PM me



___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Packaging (was: I give up)

[Greg Hellings]

On Wed, May 13, 2020 at 5:55 PM Troy A. Griffitts 
wrote:

> Has anyone tried any of the packaging tools based on containers, like
> flatpak?
>
Is that how those are implemented? I was curious but hadn't taken the time
to look under the hood.

Someone in the Xiphos world looked into one of them (Snap, I believe) and
noticed a few shortcomings for a good experience. Namely, Xiphos stores
data in ~/.xiphos (and ~/.sword, following Sword's defaults) and doesn't
honor either command-line flags or environment variables to change those.
This was incompatible with Snap's architecture which sandboxes the
application and apparently prevents access to that part of the filesystem,
or something like that? I was never sure of the specifics, but the result
was an inability to install modules or save Xiphos configuration options.
Neither of these issues is insurmountable, but it isn't one that's been
tackled right now.

The above is from memory, so it might be off on the details a little, but
it indicated that someone was trying. Flatpak is, of course, the version
that's supported most widely (and natively by Fedora and Gnome).

--Greg

> On 5/13/20 3:30 PM, Michael H wrote:
>
> On Ubuntu, I've gone to PPA version for LibreOffice... which is a newer
> version than was released under Ubuntu 18 LTS. However, it's not as easy to
> go to PPA for sword apps because there are more interactions with
> dependencies between the sword engine, gnome, etc.
>
> Back in 2002 to 04 time frame:  I was trying to build for palmOS, and ran
> into this dependencies won't line up, i need multiple minor revisions of
> the same thing to make everything work.  I and ended up getting somebody to
> "staticly compile" apps for me on the linux side, so my work on palm
> wouldn't be falling into dependency gap. It increases the size of the
> package, but no longer depends on anything outside the package. In today's
> environment of massive amounts of RAM and disk space, i don't see why any
> 'application' on linux doesn't do this... pulling in the libraries and
> having an extra copy of them makes them far more stable, and it makes them
> run quicker.  It does consume more memory and disk space, but the days when
> there was any risk of running out of ram or disk space on desktops are into
> double digits gone by.
>
> On Wed, May 13, 2020 at 4:39 PM Greg Hellings 
> wrote:
>
>>
>>
>> On Wed, May 13, 2020 at 4:28 PM Tom Sullivan 
>> wrote:
>>
>>> Greg:
>>>
>>> The repositories do not contain the latest versions. For example, the
>>> Debian Buster repository presents Xiphos 4.1, not the latest 4.2.
>>>
>>
>> 1) This is the benefit and curse of Debian. It refuses to let new
>> versions of packages in that are not bugfix and ONLY bugfix. Nothing with
>> new features at all is allowed into a stable/released version of Debian.
>> It's a benefit to users who need the stability (read: server administrators
>> and people who develop software for running on those stable versions of
>> Debian) but it's a terrible experience for end users. If you're using
>> Debian anything (other than sid, their testing release) for an end-user
>> desktop, then you're going to have a bad experience.
>>
>> 2) This is, again, an issue with the distro, and not with Crosswire or
>> Xiphos. There is nothing we can do to affect upstream's release cadence and
>> rules. Now, if the Xiphos project had enough developer manpower to maintain
>> patches to the 4.1 series as well as continue development towards 4.2, then
>> maybe we'd be able to get a 4.1.1 and 4.1.2 into old Debian versions.
>> That's what large projects do (like Debian itself), but we just don't have
>> the developer bandwidth to maintain multiple branches on any of our
>> software. But none of our software is intended for server, long-lived
>> boxes, either. It's all end user focused stuff.
>>
>>
>>> That is how I ended up reporting bugs that had been fixed. It is a wide
>>> problem; I mention Xiphos, not as a bad example, but because I happened
>>> to remember the version numbers.
>>>
>>
>> The same would be true of Sword. 1.8.1 is not just a bugfix release of
>> the 1.8 series. It introduced some minor new functionality so, technically,
>> it would not have been permitted into the Debian repository if anyone was
>> checking closely. This is just how we handle our software, again, because
>> we lack the manpower to keep multiple development streams flowing.
>>
>> I would, again, submit that your issue is actually with your chosen
>> distribution. Its documentation appears to be inadequate, and it's lulled
>> you into using a distribution that's not targeting your use case. You might
>> try running Fedora (or Ubuntu and not staying on LTS versions) which have
>> much more generous update policies. I can tell you, for instance, that
>> Xiphos compiles very nicely on current Fedora versions with a few very
>> simple commands. I happen to know this because I maintain both our Xiphos
>> CI process and the packages in the 

[sword-devel] Packaging (was: I give up)

[Troy A. Griffitts]

Has anyone tried any of the packaging tools based on containers, like
flatpak?

On 5/13/20 3:30 PM, Michael H wrote:
> On Ubuntu, I've gone to PPA version for LibreOffice... which is a
> newer version than was released under Ubuntu 18 LTS. However, it's not
> as easy to go to PPA for sword apps because there are more
> interactions with dependencies between the sword engine, gnome, etc.  
>
> Back in 2002 to 04 time frame:  I was trying to build for palmOS, and
> ran into this dependencies won't line up, i need multiple minor
> revisions of the same thing to make everything work.  I and ended up
> getting somebody to "staticly compile" apps for me on the linux side,
> so my work on palm wouldn't be falling into dependency gap. It
> increases the size of the package, but no longer depends on anything
> outside the package. In today's environment of massive amounts of RAM
> and disk space, i don't see why any 'application' on linux doesn't do
> this... pulling in the libraries and having an extra copy of them
> makes them far more stable, and it makes them run quicker.  It does
> consume more memory and disk space, but the days when there was any
> risk of running out of ram or disk space on desktops are into double
> digits gone by.  
>
> On Wed, May 13, 2020 at 4:39 PM Greg Hellings  > wrote:
>
>
>
> On Wed, May 13, 2020 at 4:28 PM Tom Sullivan  > wrote:
>
> Greg:
>
> The repositories do not contain the latest versions. For
> example, the
> Debian Buster repository presents Xiphos 4.1, not the latest 4.2.
>
>
> 1) This is the benefit and curse of Debian. It refuses to let new
> versions of packages in that are not bugfix and ONLY bugfix.
> Nothing with new features at all is allowed into a stable/released
> version of Debian. It's a benefit to users who need the stability
> (read: server administrators and people who develop software for
> running on those stable versions of Debian) but it's a terrible
> experience for end users. If you're using Debian anything (other
> than sid, their testing release) for an end-user desktop, then
> you're going to have a bad experience.
>
> 2) This is, again, an issue with the distro, and not with
> Crosswire or Xiphos. There is nothing we can do to affect
> upstream's release cadence and rules. Now, if the Xiphos project
> had enough developer manpower to maintain patches to the 4.1
> series as well as continue development towards 4.2, then maybe
> we'd be able to get a 4.1.1 and 4.1.2 into old Debian versions.
> That's what large projects do (like Debian itself), but we just
> don't have the developer bandwidth to maintain multiple branches
> on any of our software. But none of our software is intended for
> server, long-lived boxes, either. It's all end user focused stuff.
>
>
> That is how I ended up reporting bugs that had been fixed. It
> is a wide
> problem; I mention Xiphos, not as a bad example, but because I
> happened
> to remember the version numbers.
>
>
> The same would be true of Sword. 1.8.1 is not just a bugfix
> release of the 1.8 series. It introduced some minor new
> functionality so, technically, it would not have been permitted
> into the Debian repository if anyone was checking closely. This is
> just how we handle our software, again, because we lack the
> manpower to keep multiple development streams flowing.
>
> I would, again, submit that your issue is actually with your
> chosen distribution. Its documentation appears to be inadequate,
> and it's lulled you into using a distribution that's not targeting
> your use case. You might try running Fedora (or Ubuntu and not
> staying on LTS versions) which have much more generous update
> policies. I can tell you, for instance, that Xiphos compiles very
> nicely on current Fedora versions with a few very simple commands.
> I happen to know this because I maintain both our Xiphos CI
> process and the packages in the repositories for Xiphos. Now, I
> haven't updated the packages to 4.2.1 yet, for Xiphos, because I
> was busy helping with the CI and the release of 4.2.1, but due to
> the CI I know that compiling for Fedora 32 will be a breeze.
>
> Compiling for Ubuntu is a little more of a challenge, because of
> the missing dependencies, but Caleb is working on create a
> dedicated repository on Ubuntu's infrastructure just for that. And
> Caleb, myself, Dom, and Karl are all working to resolve those
> issues so that, in the future, a 4.3 or 4.4 will be able to make
> it back into the Debian repos and eventually into the Ubuntu
> "universe" repositories.
>
> So maybe give us a shot, still, on a distro that's meant for you? :)
>
> --Greg
>
>
> Tom
>
> Tom Sullivan
>   

Re: [sword-devel] I give up

[Michael H]

On Ubuntu, I've gone to PPA version for LibreOffice... which is a newer
version than was released under Ubuntu 18 LTS. However, it's not as easy to
go to PPA for sword apps because there are more interactions with
dependencies between the sword engine, gnome, etc.

Back in 2002 to 04 time frame:  I was trying to build for palmOS, and ran
into this dependencies won't line up, i need multiple minor revisions of
the same thing to make everything work.  I and ended up getting somebody to
"staticly compile" apps for me on the linux side, so my work on palm
wouldn't be falling into dependency gap. It increases the size of the
package, but no longer depends on anything outside the package. In today's
environment of massive amounts of RAM and disk space, i don't see why any
'application' on linux doesn't do this... pulling in the libraries and
having an extra copy of them makes them far more stable, and it makes them
run quicker.  It does consume more memory and disk space, but the days when
there was any risk of running out of ram or disk space on desktops are into
double digits gone by.

On Wed, May 13, 2020 at 4:39 PM Greg Hellings 
wrote:

>
>
> On Wed, May 13, 2020 at 4:28 PM Tom Sullivan  wrote:
>
>> Greg:
>>
>> The repositories do not contain the latest versions. For example, the
>> Debian Buster repository presents Xiphos 4.1, not the latest 4.2.
>>
>
> 1) This is the benefit and curse of Debian. It refuses to let new versions
> of packages in that are not bugfix and ONLY bugfix. Nothing with new
> features at all is allowed into a stable/released version of Debian. It's a
> benefit to users who need the stability (read: server administrators and
> people who develop software for running on those stable versions of Debian)
> but it's a terrible experience for end users. If you're using Debian
> anything (other than sid, their testing release) for an end-user desktop,
> then you're going to have a bad experience.
>
> 2) This is, again, an issue with the distro, and not with Crosswire or
> Xiphos. There is nothing we can do to affect upstream's release cadence and
> rules. Now, if the Xiphos project had enough developer manpower to maintain
> patches to the 4.1 series as well as continue development towards 4.2, then
> maybe we'd be able to get a 4.1.1 and 4.1.2 into old Debian versions.
> That's what large projects do (like Debian itself), but we just don't have
> the developer bandwidth to maintain multiple branches on any of our
> software. But none of our software is intended for server, long-lived
> boxes, either. It's all end user focused stuff.
>
>
>> That is how I ended up reporting bugs that had been fixed. It is a wide
>> problem; I mention Xiphos, not as a bad example, but because I happened
>> to remember the version numbers.
>>
>
> The same would be true of Sword. 1.8.1 is not just a bugfix release of the
> 1.8 series. It introduced some minor new functionality so, technically, it
> would not have been permitted into the Debian repository if anyone was
> checking closely. This is just how we handle our software, again, because
> we lack the manpower to keep multiple development streams flowing.
>
> I would, again, submit that your issue is actually with your chosen
> distribution. Its documentation appears to be inadequate, and it's lulled
> you into using a distribution that's not targeting your use case. You might
> try running Fedora (or Ubuntu and not staying on LTS versions) which have
> much more generous update policies. I can tell you, for instance, that
> Xiphos compiles very nicely on current Fedora versions with a few very
> simple commands. I happen to know this because I maintain both our Xiphos
> CI process and the packages in the repositories for Xiphos. Now, I haven't
> updated the packages to 4.2.1 yet, for Xiphos, because I was busy helping
> with the CI and the release of 4.2.1, but due to the CI I know that
> compiling for Fedora 32 will be a breeze.
>
> Compiling for Ubuntu is a little more of a challenge, because of the
> missing dependencies, but Caleb is working on create a dedicated repository
> on Ubuntu's infrastructure just for that. And Caleb, myself, Dom, and Karl
> are all working to resolve those issues so that, in the future, a 4.3 or
> 4.4 will be able to make it back into the Debian repos and eventually into
> the Ubuntu "universe" repositories.
>
> So maybe give us a shot, still, on a distro that's meant for you? :)
>
> --Greg
>
>>
>> Tom
>>
>> Tom Sullivan
>> i...@beforgiven.info
>> FAX: 815-301-2835
>> -
>>
>> On 5/13/20 5:21 PM, Greg Hellings wrote:
>> >
>> >
>> > On Wed, May 13, 2020 at 3:57 PM Tom Sullivan > > > wrote:
>> >
>> > Y'all:
>> >
>> > First, I recognize that as a writer and long retired developer and
>> > engineer (and thus obsolete) that in terms of technical issues, I am
>> > way
>> > out of my league with all you C++ programmers and experts.
>> >
>> > Second, I want to 

Re: [sword-devel] I give up

[Greg Hellings]

On Wed, May 13, 2020 at 4:28 PM Tom Sullivan  wrote:

> Greg:
>
> The repositories do not contain the latest versions. For example, the
> Debian Buster repository presents Xiphos 4.1, not the latest 4.2.
>

1) This is the benefit and curse of Debian. It refuses to let new versions
of packages in that are not bugfix and ONLY bugfix. Nothing with new
features at all is allowed into a stable/released version of Debian. It's a
benefit to users who need the stability (read: server administrators and
people who develop software for running on those stable versions of Debian)
but it's a terrible experience for end users. If you're using Debian
anything (other than sid, their testing release) for an end-user desktop,
then you're going to have a bad experience.

2) This is, again, an issue with the distro, and not with Crosswire or
Xiphos. There is nothing we can do to affect upstream's release cadence and
rules. Now, if the Xiphos project had enough developer manpower to maintain
patches to the 4.1 series as well as continue development towards 4.2, then
maybe we'd be able to get a 4.1.1 and 4.1.2 into old Debian versions.
That's what large projects do (like Debian itself), but we just don't have
the developer bandwidth to maintain multiple branches on any of our
software. But none of our software is intended for server, long-lived
boxes, either. It's all end user focused stuff.


> That is how I ended up reporting bugs that had been fixed. It is a wide
> problem; I mention Xiphos, not as a bad example, but because I happened
> to remember the version numbers.
>

The same would be true of Sword. 1.8.1 is not just a bugfix release of the
1.8 series. It introduced some minor new functionality so, technically, it
would not have been permitted into the Debian repository if anyone was
checking closely. This is just how we handle our software, again, because
we lack the manpower to keep multiple development streams flowing.

I would, again, submit that your issue is actually with your chosen
distribution. Its documentation appears to be inadequate, and it's lulled
you into using a distribution that's not targeting your use case. You might
try running Fedora (or Ubuntu and not staying on LTS versions) which have
much more generous update policies. I can tell you, for instance, that
Xiphos compiles very nicely on current Fedora versions with a few very
simple commands. I happen to know this because I maintain both our Xiphos
CI process and the packages in the repositories for Xiphos. Now, I haven't
updated the packages to 4.2.1 yet, for Xiphos, because I was busy helping
with the CI and the release of 4.2.1, but due to the CI I know that
compiling for Fedora 32 will be a breeze.

Compiling for Ubuntu is a little more of a challenge, because of the
missing dependencies, but Caleb is working on create a dedicated repository
on Ubuntu's infrastructure just for that. And Caleb, myself, Dom, and Karl
are all working to resolve those issues so that, in the future, a 4.3 or
4.4 will be able to make it back into the Debian repos and eventually into
the Ubuntu "universe" repositories.

So maybe give us a shot, still, on a distro that's meant for you? :)

--Greg

>
> Tom
>
> Tom Sullivan
> i...@beforgiven.info
> FAX: 815-301-2835
> -
>
> On 5/13/20 5:21 PM, Greg Hellings wrote:
> >
> >
> > On Wed, May 13, 2020 at 3:57 PM Tom Sullivan  > > wrote:
> >
> > Y'all:
> >
> > First, I recognize that as a writer and long retired developer and
> > engineer (and thus obsolete) that in terms of technical issues, I am
> > way
> > out of my league with all you C++ programmers and experts.
> >
> > Second, I want to thank all of you for your hard work. Compared to
> what
> > is available for Windows and Mac users, available Bible software and
> > tools are sparse. You work as volunteers and on a shoestring budget.
> > Very many thanks. Without your work, I would be back to books and
> paper
> > without being able to search, compare versions, etc., with such ease.
> > Linux users are definitely an under served people group and you fill
> a
> > big need.
> >
> > Some of you may remember my SwordHammer project. Frankly, it has
> > crashed
> > and burned. Due to an architecture decision that was not the best, it
> > became unwieldy. And now, due to changes in my life, I cannot
> continue,
> > though I had started on a new architecture. This has two
> consequences:
> > 1. There probably is not any longer reason to continue on this list
> > much
> > longer.
> > 2. I got an appreciation for the huge problem caused by incompatible
> > Linux distros. For example, I did not know that Ubuntu users were
> > limited to sudo, instead of being able to run as root.
> >
> > Many of my previous interactions with this list have been caused by
> my
> > use of obsolete versions. I cannot help it. I seem only able to
> 

Re: [sword-devel] I give up

[Tom Sullivan]

Greg:

The repositories do not contain the latest versions. For example, the 
Debian Buster repository presents Xiphos 4.1, not the latest 4.2.


That is how I ended up reporting bugs that had been fixed. It is a wide 
problem; I mention Xiphos, not as a bad example, but because I happened 
to remember the version numbers.


Tom

Tom Sullivan
i...@beforgiven.info
FAX: 815-301-2835
-

On 5/13/20 5:21 PM, Greg Hellings wrote:



On Wed, May 13, 2020 at 3:57 PM Tom Sullivan > wrote:


Y'all:

First, I recognize that as a writer and long retired developer and
engineer (and thus obsolete) that in terms of technical issues, I am
way
out of my league with all you C++ programmers and experts.

Second, I want to thank all of you for your hard work. Compared to what
is available for Windows and Mac users, available Bible software and
tools are sparse. You work as volunteers and on a shoestring budget.
Very many thanks. Without your work, I would be back to books and paper
without being able to search, compare versions, etc., with such ease.
Linux users are definitely an under served people group and you fill a
big need.

Some of you may remember my SwordHammer project. Frankly, it has
crashed
and burned. Due to an architecture decision that was not the best, it
became unwieldy. And now, due to changes in my life, I cannot continue,
though I had started on a new architecture. This has two consequences:
1. There probably is not any longer reason to continue on this list
much
longer.
2. I got an appreciation for the huge problem caused by incompatible
Linux distros. For example, I did not know that Ubuntu users were
limited to sudo, instead of being able to run as root.

Many of my previous interactions with this list have been caused by my
use of obsolete versions. I cannot help it. I seem only able to install
packages from the Debian repository (or download a *.deb suitable for
Debian Buster and install). I recently tried to compile and install
Sword (which worked), BibleTime (which crashed), and Xiphos (which I
was
not able to compile by various tries.) There are errors in the docs,
and
discrepancies between docs, and who knows what.) I failed. So I am
stuck, and that is not mainly your fault. The problem is that there is
no Linux-wide packaging or installation system. It may or may not be
technically feasible, I don't know). When things go wrong, I often have
no idea how to fix them.


You really shouldn't have to download any files. You should only have to 
run "sudo apt update && sudo apt install bibletime". Or, if you want to 
compile BibleTime from source but use the packaged Sword library, "sudo 
apt install libsword-dev". Currently, Xiphos is not compatible with 
Debian/Ubuntu because it depends on ancient libraries that are not 
available in those distributions anymore. However, packagers for those 
distros, until recently, were maintaining a heavily patched version of 
Xiphos that was avilable in their repositories. All that was needed was 
"sudo apt install xiphos". No downloading or building or manually 
finding dependencies.



So I have two suggestions here, but let me start with an analogy.
When I
have to buy a new vehicle, my concern is not if the seat is nice and
the
radio works and the vanity light works. I want it to safely take me
where I want to go. If there is a rip in the seat or dents in the body
or some rust or something, I can live with that. So, I am willing to
live with what is in the repositories and not waste everybody else's
time with bug reports. I apologize for doing that. It was not
intentional, but that is what happened.

Suggestion 1: Clean up documentation. Prime exhibit: May Crosswire page
refers to Sword 1.8.0 with link for months with no mention of 1.8.1.


I'm not sure where you're looking. This is the download page for Sword 
source http://crosswire.org/sword/develop/index.jsp and it mentions 
1.8.1 without incident.



Suggestion 2: For the more popular distros, provide ready-to-go
packages, .deb files (or equivalent, such as .rpm) for installs and
updates, even if they do not hit the repositories until later. This
will
get users access who are not experts. In my opinion, for what it is
worth, this is at least as important as new features. Also allow users
an option to automatically check for updates and tell where to get a
new
package. I understand that this takes time and work. I would rather get
some new features and bug fixes, and be able to get and use them, than
new features I will never see because I can't compile or something. I
rather think that others are also in my position as well.


This is usually a Very Bad Idea for upstream projects. Every distro has 
its own quirks, 

Re: [sword-devel] I give up

[Greg Hellings]

On Wed, May 13, 2020 at 3:57 PM Tom Sullivan  wrote:

> Y'all:
>
> First, I recognize that as a writer and long retired developer and
> engineer (and thus obsolete) that in terms of technical issues, I am way
> out of my league with all you C++ programmers and experts.
>
> Second, I want to thank all of you for your hard work. Compared to what
> is available for Windows and Mac users, available Bible software and
> tools are sparse. You work as volunteers and on a shoestring budget.
> Very many thanks. Without your work, I would be back to books and paper
> without being able to search, compare versions, etc., with such ease.
> Linux users are definitely an under served people group and you fill a
> big need.
>
> Some of you may remember my SwordHammer project. Frankly, it has crashed
> and burned. Due to an architecture decision that was not the best, it
> became unwieldy. And now, due to changes in my life, I cannot continue,
> though I had started on a new architecture. This has two consequences:
> 1. There probably is not any longer reason to continue on this list much
> longer.
> 2. I got an appreciation for the huge problem caused by incompatible
> Linux distros. For example, I did not know that Ubuntu users were
> limited to sudo, instead of being able to run as root.
>
> Many of my previous interactions with this list have been caused by my
> use of obsolete versions. I cannot help it. I seem only able to install
> packages from the Debian repository (or download a *.deb suitable for
> Debian Buster and install). I recently tried to compile and install
> Sword (which worked), BibleTime (which crashed), and Xiphos (which I was
> not able to compile by various tries.) There are errors in the docs, and
> discrepancies between docs, and who knows what.) I failed. So I am
> stuck, and that is not mainly your fault. The problem is that there is
> no Linux-wide packaging or installation system. It may or may not be
> technically feasible, I don't know). When things go wrong, I often have
> no idea how to fix them.
>

You really shouldn't have to download any files. You should only have to
run "sudo apt update && sudo apt install bibletime". Or, if you want to
compile BibleTime from source but use the packaged Sword library, "sudo apt
install libsword-dev". Currently, Xiphos is not compatible with
Debian/Ubuntu because it depends on ancient libraries that are not
available in those distributions anymore. However, packagers for those
distros, until recently, were maintaining a heavily patched version of
Xiphos that was avilable in their repositories. All that was needed was
"sudo apt install xiphos". No downloading or building or manually finding
dependencies.


> So I have two suggestions here, but let me start with an analogy. When I
> have to buy a new vehicle, my concern is not if the seat is nice and the
> radio works and the vanity light works. I want it to safely take me
> where I want to go. If there is a rip in the seat or dents in the body
> or some rust or something, I can live with that. So, I am willing to
> live with what is in the repositories and not waste everybody else's
> time with bug reports. I apologize for doing that. It was not
> intentional, but that is what happened.
>
> Suggestion 1: Clean up documentation. Prime exhibit: May Crosswire page
> refers to Sword 1.8.0 with link for months with no mention of 1.8.1.
>

I'm not sure where you're looking. This is the download page for Sword
source http://crosswire.org/sword/develop/index.jsp and it mentions 1.8.1
without incident.


> Suggestion 2: For the more popular distros, provide ready-to-go
> packages, .deb files (or equivalent, such as .rpm) for installs and
> updates, even if they do not hit the repositories until later. This will
> get users access who are not experts. In my opinion, for what it is
> worth, this is at least as important as new features. Also allow users
> an option to automatically check for updates and tell where to get a new
> package. I understand that this takes time and work. I would rather get
> some new features and bug fixes, and be able to get and use them, than
> new features I will never see because I can't compile or something. I
> rather think that others are also in my position as well.
>

This is usually a Very Bad Idea for upstream projects. Every distro has its
own quirks, foibles, and differences. For instance, gtkhtml is still
avilable on Fedora but not on Ubuntu or Debian. As such, Xiphos can be
compiled rather readily on Fedora but not on Debian/Ubuntu without heavy
patching of the source to disable the editor features. Those are details
already managed by the packagers of those distributions and are quite a
nightmare for every upstream project to keep track of. Nor is it easy to
keep separate the very tiny tweaks that make up the Debian -> Ubuntu ->
Mint/Pop/etc food chain where downstream distributions consume upstream
packages in some manner. Providing a build is not something upstream

[sword-devel] I give up

[Tom Sullivan]

Y'all:

First, I recognize that as a writer and long retired developer and 
engineer (and thus obsolete) that in terms of technical issues, I am way 
out of my league with all you C++ programmers and experts.


Second, I want to thank all of you for your hard work. Compared to what 
is available for Windows and Mac users, available Bible software and 
tools are sparse. You work as volunteers and on a shoestring budget. 
Very many thanks. Without your work, I would be back to books and paper 
without being able to search, compare versions, etc., with such ease. 
Linux users are definitely an under served people group and you fill a 
big need.


Some of you may remember my SwordHammer project. Frankly, it has crashed 
and burned. Due to an architecture decision that was not the best, it 
became unwieldy. And now, due to changes in my life, I cannot continue, 
though I had started on a new architecture. This has two consequences:
1. There probably is not any longer reason to continue on this list much 
longer.
2. I got an appreciation for the huge problem caused by incompatible 
Linux distros. For example, I did not know that Ubuntu users were 
limited to sudo, instead of being able to run as root.


Many of my previous interactions with this list have been caused by my 
use of obsolete versions. I cannot help it. I seem only able to install 
packages from the Debian repository (or download a *.deb suitable for 
Debian Buster and install). I recently tried to compile and install 
Sword (which worked), BibleTime (which crashed), and Xiphos (which I was 
not able to compile by various tries.) There are errors in the docs, and 
discrepancies between docs, and who knows what.) I failed. So I am 
stuck, and that is not mainly your fault. The problem is that there is 
no Linux-wide packaging or installation system. It may or may not be 
technically feasible, I don't know). When things go wrong, I often have 
no idea how to fix them.


So I have two suggestions here, but let me start with an analogy. When I 
have to buy a new vehicle, my concern is not if the seat is nice and the 
radio works and the vanity light works. I want it to safely take me 
where I want to go. If there is a rip in the seat or dents in the body 
or some rust or something, I can live with that. So, I am willing to 
live with what is in the repositories and not waste everybody else's 
time with bug reports. I apologize for doing that. It was not 
intentional, but that is what happened.


Suggestion 1: Clean up documentation. Prime exhibit: May Crosswire page 
refers to Sword 1.8.0 with link for months with no mention of 1.8.1.


Suggestion 2: For the more popular distros, provide ready-to-go 
packages, .deb files (or equivalent, such as .rpm) for installs and 
updates, even if they do not hit the repositories until later. This will 
get users access who are not experts. In my opinion, for what it is 
worth, this is at least as important as new features. Also allow users 
an option to automatically check for updates and tell where to get a new 
package. I understand that this takes time and work. I would rather get 
some new features and bug fixes, and be able to get and use them, than 
new features I will never see because I can't compile or something. I 
rather think that others are also in my position as well.


For what it is worth, and sorry it is so long. Sorry again for wasting 
all your time in the past. God bless you and keep up all the good work. 
It is not perfect, but it is definitely good and I use your stuff many 
hours a week and every day.


Sincerely,
Tom Sullivan

--
Tom Sullivan
i...@beforgiven.info
FAX: 815-301-2835
-


___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page