Re: [FLEx] Installing FLEx 8 on Linux

18 views
Skip to first unread message

Beth-docs Bryson

unread,
Oct 4, 2020, 3:24:36 PM10/4/20
to 'Rand Valentine' via FLEx list, flex-o...@googlegroups.com
Mark-

At the time you first asked, FW 9.0 was still a “release candidate”, so it was on “experimental” instead of “main”. However, since then it has been declared “stable”, so now it is the only one available on “main”.

Mark Strobert raised some interesting thoughts about whether FW 8.3 should continue to be available on Linux.  I am cross-posting to the FLEx-on-Linux list, because someone else asked something similar there.

-Beth

On Oct 3, 2020, at 9:22 AM, Mark Simmons <mark.sim...@gmail.com> wrote:

PS. I tried disabling experimental software and it was never enabled in the first place, the only version I see is still version 9.

Em sábado, 3 de outubro de 2020 às 09:22:20 UTC-5, Mark Simmons escreveu:
Hi Mark,

When I tried version 9 I had some stability issues (it crashed more) and also there was an error whenever I tried to import a .LIFT, which was the main dealbreaker as I was doing a lot of edits on the db through the LIFT API at the time. I see that version 9 is now stable, so the crashes might no longer be an issue, but I had made a lot of edits on version 9 which are now outdated with respect to our project stored in version 8. Thus, if we were to upgrade and these versions merged it would make us lose a lot of progress.

Being the only linux user on my team, I don't want to make the rest have to upgrade to accomodate me. Are you able to send me the install files for version 8? I had downgraded OS on my desktop to ubuntu 18.04 and managed to install FLEx version 8 before version 9 was put up, but I didn't get there in time to put it on my work laptop.

Thanks,
- Mark
Em sexta-feira, 18 de setembro de 2020 às 13:02:59 UTC-5, MarkS escreveu:
Mark,

By the way, it may be that you are only seeing FW 9 and not FW 8.3 because of having the 'Beta' (aka 'experimental') area of packages.sil.org enabled.

If you are using Wasta/Ubuntu 18.04 (bionic) or 16.04 (xenial), and only have FieldWorks 9 available, you can try turning off the Beta ("experimental") repository of packages.sil.org. If you're not familiar with how to do that, see http://packages.sil.org/details.html under
    Install Beta SIL software > Turn off Beta SIL software repository
Don't be afraid to ask an IT friend for help (or reply here and I can provide more guidance). Fiddling with package repo selection can be a bit advanced.

Downgrading from Linux FieldWorks 9 to Linux FieldWorks 8.3 is not something we really ever exercise in testing, but it should be possible to do by turning off the Beta ("experimental") area of packages.sil.org, keeping the main non-Beta usage of packages.sil.org enabled, reloading repo package lists ("sudo apt update"), uninstalling fieldworks, fieldworks-applications, and flexbridge packages ("sudo apt remove fieldworks fieldworks-applications flexbridge"), and then installing fieldworks ("sudo apt install fieldworks").

In Wasta/Ubuntu 18.04 (bionic) and 16.04 (xenial), this should result in having FieldWorks 8.3 installed.
In Wasta/Ubuntu 20.04 (focal), there is no FieldWorks 8.3 available to install, so don't bother with these steps if you are using Wasta/Ubuntu 20.04 (focal).

It will be very helpful to report any FieldWorks 9 bugs so FieldWorks 9 can work with projects like yours.

Mark


On Friday, September 18, 2020 at 10:23:33 AM UTC-6 MarkS wrote:
Hey Mark, thanks for asking about that. In the past, we have not been providing multiple stable FW versions for Linux, but this is the kind of thing that may need us to move in that direction.

FieldWorks 8.3.13 is available at packages.sil.org for Wasta/Ubuntu 18.04 (bionic) and 16.04 (xenial). You should be able to install FieldWorks 8.3 easily if you are running one of those.
However, only FieldWorks 9 is available for Wasta/Ubuntu 20.04 (focal).

When we ship a new FieldWorks stable release, we overwrite the current release in the main area of packages.sil.org. That means that when FW 9 is shipped as a stable release on Linux, it will overwrite the FieldWorks 8.3 packages on packages.sil.org. But your message gives me pause to consider what we should do. The current plan has been to release FW 9 to the main area of packages.sil.org next week, so now is a good time to get FW 8.3 (and pin the version or something to prevent it from upgrading).

I think an important consideration in this is why your team is having trouble migrating to FieldWorks version 9. If it regards bugs or usability issues in the software, it will help to report them (via the Help menu), as the FieldWorks team will want to know about these problems and get them fixed.
If it regards difficulty with project data, you can contact FieldWorks support as well and they may be able to direct you to successfully upgrade your data and use FieldWorks 9.



On Friday, September 18, 2020 at 9:27:19 AM UTC-6 mark.sim...@gmail.com wrote:
Hi all,

As far as I can tell, only FLEx version 9 is available for install on Linux. However, my team (the rest using windows) is using version 8 since we ran into problems when we tried to migrate to version 9. Is there a way to install FLEx version 8 on Linux?

--
"FLEx list" messages are public. Only members can post.
flex_d...@sil.org
http://groups.google.com/group/flex-list.
---
You received this message because you are subscribed to the Google Groups "FLEx list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flex-list+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/flex-list/4bd58220-d959-4c3d-8ff8-36c8bcd8deebn%40googlegroups.com.

Kim Blewett (gmail)

unread,
Oct 5, 2020, 8:42:14 AM10/5/20
to flex-o...@googlegroups.com

I have been involved in previous discussions about the question of whether FLEx-Linux could be made to allow two versions to be installed on a Linux computer, similar to how Paratext and Bloom often have older and newer versions available with different package names. This would make life much easier for language teams with members located remotely, especially when some team members have limited, or no, internet access. (I like the PT pattern of including the major version number in the package name.)

Seems like every time FLEx upgrades its underlying database model, some language teams get "stuck" because someone accidentally installed the new version and upgraded the database, breaking the S/R availability until every other member could also upgrade to the new version.

What makes this difficult to prevent (for the sake of readers who are puzzled about what has happened) is when I want the beta version of Bloom or Paratext for some specific feature: I can enable the -experimental repo and install just the beta program that I need, then disable -experimental again until I need to upgrade that program. However, beta versions need upgrading often by their very nature. If I accidentally upgrade the full system while -experimental is enabled I get the new FW automatically. Then I open FLEx, puzzle a bit about the "upgrading" message ... Uh oh! By then my database is no longer compatible with my teammates'.

Likewise, some multilanguage advisors and admins need to work with both the old and new versions for their advisee teams. It would be a great help if both versions could be usable on one computer for a good length of time when FLEx upgrades require upgrading the data model, please.

Thanks,

Kim

--
--
You received this message because you are subscribed to the FLEx on Linux group, hosted by Google Groups.
The list and all posts are visible to anyone on the Internet, but you must be a member to post.
To post to this group, send email to flex-o...@googlegroups.com.
To unsubscribe from this group, send email to flex-on-linu...@googlegroups.com.
For more options or to subscribe, visit this group at https://groups.google.com/d/forum/flex-on-linux?hl=en
---
You received this message because you are subscribed to the Google Groups "FLEx on Linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flex-on-linu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/flex-on-linux/7311FD97-EAF3-4062-B411-2C4D7845E377%40sil.org.

Beth-docs Bryson

unread,
Oct 5, 2020, 4:26:52 PM10/5/20
to flex-o...@googlegroups.com, mar...@gmail.com
I posted this to the FLEx list, but I meant to post it to flex-on-linux.

Begin forwarded message:

From: Beth-docs Bryson <beth-doc...@sil.org>
Subject: Re: [FLEx] Installing FLEx 8 on Linux
Date: October 5, 2020 at 3:25:00 PM CDT
To: FLEx list <flex...@googlegroups.com>

Mark,

On Oct 5, 2020, at 2:44 PM, Mark S <mar...@gmail.com> wrote:

> Being the only linux user on my team, I don't want to make the rest have to upgrade to accomodate me. Are you able to send me the install files for version 8? I

Yes! Our conversation before prompted me to preserve the FW 8.3 packages before they got overwritten. I just made a note to post those for you, hopefully this week.


I hope you will post on the FLEx-on-Linux list once you have instructions for accessing those preserved packages.  There are a number of people asking about it.  It is a non-standard procedure, but it sounds like it’s a really good thing that you preserved those packages!

-Beth


Message has been deleted
Message has been deleted

ann_...@sil.org

unread,
Oct 6, 2020, 3:28:27 PM10/6/20
to flex-o...@googlegroups.com

I like the idea of being able to choose which version of FLEx to install, like Windows.  I like having a choice.

 

Ann

 

From: flex-o...@googlegroups.com <flex-o...@googlegroups.com> On Behalf Of Mark S
Sent: Tuesday, October 6, 2020 10:49 AM
To: FLEx on Linux <flex-o...@googlegroups.com>
Subject: [Linux FLEx] Re: FieldWorks 8 vs 9 choice of installation helpful?

 

Whoops, that was supposed to be in a new thread. I will delete my previous message.

On Tuesday, October 6, 2020 at 9:45:41 AM UTC-6 Mark S wrote:

Hello,

 

I'd like to hear more voices on this.

 

Paratext on Linux lets users choose to install a `paratext-8.0` package or a `paratext-9.0` package. Users running `paratext-8.0` can keep using Paratext 8 until they are ready to install Paratext 9.

FieldWorks on Linux has always just published a 'latest-stable' package. So users with FieldWorks 8.3 get automatically upgraded to FieldWorks 9.0 when FieldWorks 9 is released as a stable package.

 

FieldWorks on Linux could be changed to use version-specific packages. When installing FieldWorks, you would need to specifically choose to install `fieldworks-8.3` or `fieldworks-9.0`. You would only potentially get bugfixes, but never new features.

`fieldworks-8.3` may receive updates from 8.3.12 to 8.3.13 to 8.3.14, but never to 9.0.0.

`fieldworks-9.0` may receive updates from 9.0.12 to 9.0.13 to 9.0.14, but never to 9.1.0 (unless maybe it could share data with FW 9.0 installations).

 

Now that FW 9.0 has been shipped as a stable release, and the FieldWorks development team is very small, there won't be any more FW 8.3 updates. So using `fieldworks-8.3` would still be possible, but it would be unlikely to ever receive a bug fix.

After FW 9.1 is released as stable, `fieldworks-9.0` would continue to be installable, but would not get bug fixes.

 

Users of `fieldworks-8.3` would need to initiate a new installation of `fieldworks-9.0`, and later `fieldworks-9.1`, to get new features.

A big win for this, of course, is that users could do it on their own timetable.

 

This would work differently than most other software installed in Ubuntu. For example, if I install Gimp or LibreOffice, I expect that over time it will get upgraded from version 5 to 6 to 7, without me needing to think about it or specifically ask for it (with the exception of needing to ask my computer to upgrade). That said, I don't expect it to have any negative impact on my stored data. Conversely, FieldWorks upgrades projects when they are opened in a new FW version, making the project incompatible with older FW versions, which can lead to difficulties when sharing projects with colleagues.

 

Would moving to version-specific packages like fieldworks-8.3 and fieldworks-9.0 be helpful to you, where you choose which version to install and when to upgrade?

Would it be more helpful to you if FieldWorks on Linux continued to be released as just 'fieldworks' and you were automatically upgraded from 8.3 to 9.0 to 9.1?

Are you indifferent?

 

Note that this does not mean both FW 8.3 and FW 9.0 would be simultaneously installable and that you could choose which you wanted to run on a given day. That would need to be a further change.

 

Thank you for any comments or insights you can provide.

Mark

 

 

On Monday, October 5, 2020 at 6:42:14 AM UTC-6 Kim B wrote:

I have been involved in previous discussions about the question of whether FLEx-Linux could be made to allow two versions to be installed on a Linux computer, similar to how Paratext and Bloom often have older and newer versions available with different package names. This would make life much easier for language teams with members located remotely, especially when some team members have limited, or no, internet access. (I like the PT pattern of including the major version number in the package name.)

Seems like every time FLEx upgrades its underlying database model, some language teams get "stuck" because someone accidentally installed the new version and upgraded the database, breaking the S/R availability until every other member could also upgrade to the new version.

What makes this difficult to prevent (for the sake of readers who are puzzled about what has happened) is when I want the beta version of Bloom or Paratext for some specific feature: I can enable the -experimental repo and install just the beta program that I need, then disable -experimental again until I need to upgrade that program. However, beta versions need upgrading often by their very nature. If I accidentally upgrade the full system while -experimental is enabled I get the new FW automatically. Then I open FLEx, puzzle a bit about the "upgrading" message ... Uh oh! By then my database is no longer compatible with my teammates'.

Likewise, some multilanguage advisors and admins need to work with both the old and new versions for their advisee teams. It would be a great help if both versions could be usable on one computer for a good length of time when FLEx upgrades require upgrading the data model, please.

Thanks,

Kim

--

--
You received this message because you are subscribed to the FLEx on Linux group, hosted by Google Groups.
The list and all posts are visible to anyone on the Internet, but you must be a member to post.
To post to this group, send email to flex-o...@googlegroups.com.
To unsubscribe from this group, send email to flex-on-linu...@googlegroups.com.
For more options or to subscribe, visit this group at https://groups.google.com/d/forum/flex-on-linux?hl=en
---
You received this message because you are subscribed to the Google Groups "FLEx on Linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flex-on-linu...@googlegroups.com.

Kim Blewett (gmail)

unread,
Oct 6, 2020, 4:53:13 PM10/6/20
to flex-o...@googlegroups.com

I like it too. Sounds like it would behave similarly to Paratext. The two versions might need to be available (1) when there is a non-reversible data model change, (2) until another new data model update comes out in beta... and/or: for at least a year or more after a publicity campaign warning people that the old one needs to be discontinued somehow. Seems like in PNG it took nearly two years to get hold of all the remote PT7 users and get them upgraded to PT8. "Remoteness" in PNG is legendary.... :)

Eberhard Beilharz

unread,
Oct 7, 2020, 2:50:42 AM10/7/20
to flex-o...@googlegroups.com

Another option would be to publish version-specific packages like `fieldworks-8.3` and `fieldworks-9.0`, but also add a meta-package `fieldworks` that depends on the latest version-specific package, i.e. in this case `fieldworks-9.0` (and would uninstall `fieldworks-8.3`).

Then the user can decide if they always want the latest version (in which case they would install `fieldworks`), or install `fieldworks-9.0` to stick with a particular version and manually upgrade to the next version at their convenience.

    Eberhard

Mark S wrote on 2020-10-06 17:45:
Hello,

I'd like to hear more voices on this.

Paratext on Linux lets users choose to install a `paratext-8.0` package or a `paratext-9.0` package. Users running `paratext-8.0` can keep using Paratext 8 until they are ready to install Paratext 9.
FieldWorks on Linux has always just published a 'latest-stable' package. So users with FieldWorks 8.3 get automatically upgraded to FieldWorks 9.0 when FieldWorks 9 is released as a stable package.

FieldWorks on Linux could be changed to use version-specific packages. When installing FieldWorks, you would need to specifically choose to install `fieldworks-8.3` or `fieldworks-9.0`. You would only potentially get bugfixes, but never new features.
`fieldworks-8.3` may receive updates from 8.3.12 to 8.3.13 to 8.3.14, but never to 9.0.0.
`fieldworks-9.0` may receive updates from 9.0.12 to 9.0.13 to 9.0.14, but never to 9.1.0 (unless maybe it could share data with FW 9.0 installations).

Now that FW 9.0 has been shipped as a stable release, and the FieldWorks development team is very small, there won't be any more FW 8.3 updates. So using `fieldworks-8.3` would still be possible, but it would be unlikely to ever receive a bug fix.
After FW 9.1 is released as stable, `fieldworks-9.0` would continue to be installable, but would not get bug fixes.

Users of `fieldworks-8.3` would need to initiate a new installation of `fieldworks-9.0`, and later `fieldworks-9.1`, to get new features.
A big win for this, of course, is that users could do it on their own timetable.

This would work differently than most other software installed in Ubuntu. For example, if I install Gimp or LibreOffice, I expect that over time it will get upgraded from version 5 to 6 to 7, without me needing to think about it or specifically ask for it (with the exception of needing to ask my computer to upgrade). That said, I don't expect it to have any negative impact on my stored data. Conversely, FieldWorks upgrades projects when they are opened in a new FW version, making the project incompatible with older FW versions, which can lead to difficulties when sharing projects with colleagues.

Would moving to version-specific packages like fieldworks-8.3 and fieldworks-9.0 be helpful to you, where you choose which version to install and when to upgrade?
Would it be more helpful to you if FieldWorks on Linux continued to be released as just 'fieldworks' and you were automatically upgraded from 8.3 to 9.0 to 9.1?
Are you indifferent?

Note that this does not mean both FW 8.3 and FW 9.0 would be simultaneously installable and that you could choose which you wanted to run on a given day. That would need to be a further change.

Thank you for any comments or insights you can provide.
Mark


On Monday, October 5, 2020 at 6:42:14 AM UTC-6 Kim B wrote:

I have been involved in previous discussions about the question of whether FLEx-Linux could be made to allow two versions to be installed on a Linux computer, similar to how Paratext and Bloom often have older and newer versions available with different package names. This would make life much easier for language teams with members located remotely, especially when some team members have limited, or no, internet access. (I like the PT pattern of including the major version number in the package name.)

Seems like every time FLEx upgrades its underlying database model, some language teams get "stuck" because someone accidentally installed the new version and upgraded the database, breaking the S/R availability until every other member could also upgrade to the new version.

What makes this difficult to prevent (for the sake of readers who are puzzled about what has happened) is when I want the beta version of Bloom or Paratext for some specific feature: I can enable the -experimental repo and install just the beta program that I need, then disable -experimental again until I need to upgrade that program. However, beta versions need upgrading often by their very nature. If I accidentally upgrade the full system while -experimental is enabled I get the new FW automatically. Then I open FLEx, puzzle a bit about the "upgrading" message ... Uh oh! By then my database is no longer compatible with my teammates'.

Likewise, some multilanguage advisors and admins need to work with both the old and new versions for their advisee teams. It would be a great help if both versions could be usable on one computer for a good length of time when FLEx upgrades require upgrading the data model, please.

Thanks,

Kim

--
--
You received this message because you are subscribed to the FLEx on Linux group, hosted by Google Groups.
The list and all posts are visible to anyone on the Internet, but you must be a member to post.
To post to this group, send email to flex-o...@googlegroups.com.
To unsubscribe from this group, send email to flex-on-linu...@googlegroups.com.
For more options or to subscribe, visit this group at https://groups.google.com/d/forum/flex-on-linux?hl=en
---
You received this message because you are subscribed to the Google Groups "FLEx on Linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flex-on-linu...@googlegroups.com.

mark.simmons94.ms

unread,
Oct 7, 2020, 10:44:57 AM10/7/20
to FLEx on Linux
Having a choice between the two would be great, whether it's as Mark suggested and flex-8.3 and 9.0 are separate packages, or whether there's those two plus a separate super package like Eberhard suggested.
Reply all
Reply to author
Forward
0 new messages