Snap improvements

[brlin-tw]

This pull request introduces various improvements to the snap recipe, please review.

[stweil]

Maybe libcurl and libarchive could be added, too. Both add more features to tesseract.

[brlin-tw]

@stweil

Maybe libcurl and libarchive could be added, too. Both add more features to tesseract.

I have plans to add them as well, will do.

[brlin-tw]

@stweil

Maybe libcurl and libarchive could be added, too. Both add more features to tesseract.

I have made the requested change, please review.

[brlin-tw]

I noticed that the snap would fail to launch due to link failure:

/snap/tesseract/x1/usr/local/bin/tesseract: error while loading shared libraries: libtesseract.so.5: cannot open shared object file: No such file or directory

Will push a fix soon.

[egorpugin]

Do we really need this selective-checkout file?

[brlin-tw]

I noticed that the snap would fail to launch due to link failure:

/snap/tesseract/x1/usr/local/bin/tesseract: error while loading shared libraries: libtesseract.so.5: cannot open shared object file: No such file or directory

This problem is fixed in the current branch tip.

I also fixed broken libcurl functionality due to missing network snapd security confinement interface connection, please review.

[brlin-tw]

@egorpugin

Do we really need this selective-checkout file?

This is required for the downstream snap publisher(currently me, but it can be anyone that has store collaborator access) to have stable(r) snap builds available to promote to the stable(r) channels on the Snap Store. Currently, the snap build is done by periodically(every 6 hours IIRC) importing this repository to the mirror repo on Launchpad, which has a snap package recipe configured to be built automatically whenever the content of the mirror changes. As the build trigger isn't based on release tags we cannot ensure that beta/rc/stable builds will be available to be promoted to the beta/candidate/stable channels on the store backstage unless the Snapcraft part pull logic is customized.

Here is an example of what the snap promote operation looks like:

It is fine to drop this file if the snap maintainer/collaborator has the Git repository's write access and is willing to manually set the release tag to build(e.g. via the source-tag property of the tesseract part) in the snapcraft.yaml as part of the release process.

[brlin-tw]

I found a problem that the Tesseract config files shipped within the snap are not loaded due to the lack of data directory fallback logic(the TESSDATA_PREFIX environment variable is set to $SNAP_USER_COMMON to allow the user to install trained data files, however the config files are installed in the readonly $SNAP/usr/local/share/tessdata directory).

tesseract ../eurotext.png - -l eng hocr
read_params_file: Can't open hocr

openat(AT_FDCWD, "/home/brlin/snap/tesseract/common/configs/hocr", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/brlin/snap/tesseract/common/tessconfigs/hocr", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "hocr", O_RDONLY)      = -1 ENOENT (No such file or directory)
write(2, "read_params_file: Can't open hoc"..., 34read_params_file: Can't open hocr
) = 34

Related code: CCUtil::main_setup function of tesseract/src/ccutil/ccutil.cpp at main · tesseract-ocr/tesseract.

I'll make a patch to handle the fallback in the meantime, but it may be desired to implement the fallback logic in the main code(User specified path -> TESSDATA_PREFIX -> hardcoded datadir during the build configuration process).

[brlin-tw]

I'll make a patch to handle the fallback in the meantime

A patch(bdccad) is implemented to workaround this issue, I can confirm read-only config files can be accessed normally. I don't really speak C++ so please do review.

[brlin-tw]

I noticed several new problems while researching the config loading issue:

• Currently the snap hardcodes the TESSDATA_PREFIX environment variable to SNAP_USER_COMMON, we should avoid doing so to allow users to set the variable to any accessible, preferable path to have a consistent experience with the native distribution.
• The TESSDATA_PREFIX hardcoded datadir macro isn't set to a valid value(should be $SNAP/usr/local/share instead of /usr/local/share, this isn't currently used as it is overridden by the hardcoded TESSDATA_PREFIX environment variable, but fixing it can simplify the aforementioned fallback config loading patch which hardcodes the entire path.)

I'll address these issues in the next couple of days.

[egorpugin]

@brlin-tw Is it possible to make tesseract-snap repo and put all snap related files there?

@stweil What do you think?

[brlin-tw]

@egorpugin

@brlin-tw Is it possible to make tesseract-snap repo and put all snap related files there?

It's definitely possible, though in this case, I'll have to figure out how to trigger an automatic snap build whenever the main repo has new changes. I'll look into it.

[brlin-tw]

• Currently the snap hardcodes the TESSDATA_PREFIX environment variable to SNAP_USER_COMMON, we should avoid doing so to allow users to set the variable to any accessible, preferable path to have a consistent experience with the native distribution.

• The TESSDATA_PREFIX hardcoded datadir macro isn't set to a valid value(should be $SNAP/usr/local/share instead of /usr/local/share, this isn't currently used as it is overridden by the hardcoded TESSDATA_PREFIX environment variable, but fixing it can simplify the aforementioned fallback config loading patch which hardcodes the entire path.)

These issues are fixed in the current tip of the branch.

[brlin-tw]

Hello, apologies for the ignorance. Here are some progress I'm doing at the moment:

• I'm now experimenting with the automation required to effectively publish Tesseract snaps in a separate repo in my brlin-tw/tesseract-snap repo, it involves borrowing some of the Snapcrafters automation implementation(and slightly customized a bit) but is still a work-in-progress.

• I previously had a problem publishing the snap and accessing the store's backstage due to a configuration issue at the store end, fortunately, it is finally resolved and is no longer a blocker.

  This also means I can now add you as the snap's collaborator which will allow you to access the store backstage and manage application releases, simply message me the mail address associated with your Ubuntu One account.

• I'm also looking into the possibility of letting the Snapcrafters organization adopt this snap if you don't prefer to manage the snap distribution as the snap would be better maintained in the long run at the cost of some flexibility(stricter contribution inclusion policy, etc.), let me know what you think.

  Update: Not an option right now as the Snapcrafters organization isn't ready to adopt new snaps.