Provide valid Linux CI builds in Releases section as well

[FriedrichFroebel]

For now, it seems like CI does some Linux builds, but only uploads them as build artifacts which expire after some time and are not accessible without being logged in to GitHub. It probably would make more sense to provide them in the Releases section as well.

Before doing so, they might require some more fixes/documentation:

• The Debian package metadata is mostly empty and the requirements seem to be undeclared?

• The RPM package metadata seems to be similar.

• The regular build fails with just "Illegal instruction".

• The AppImage build fails as well:

  qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
  This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
  
  Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.
  
  Aborted
  

By contrast: Building the package from source does not expose these problems.

Hello, @FriedrichFroebel

Are you using ubuntu as distribution? The binaries the CI system creates are built on ubuntu-latest, you need to use ubuntu as well. I'm investigating the other issues you mention.

EDIT:

The rpm and deb packages metadata seem to be fine:

rpm -qp scantailor.rpm 
scantailor-advanced-1.0.19-1.x86_64

dpkg-deb -I scantailor.deb 
 new Debian package, version 2.0.
 size 2041752 bytes: control archive=660 bytes.
     222 bytes,     9 lines      control              
     955 bytes,    11 lines      md5sums              
 Architecture: amd64
 Description: Interactive post-processing tool for scanned pages.
 Maintainer: 4lex4 <4lex49@zoho.com>
 Package: scantailor-advanced
 Priority: optional
 Section: devel
 Version: 1.0.19
 Installed-Size: 5754

[FriedrichFroebel]

I tested this on a distro based upon Ubuntu 22.04 (AFAIK it only does some irrelevant changes), which should correspond to ubuntu-latest.

The issue is not about the metadata itself, but about them being incomplete/sparse and not declaring any Qt dependencies for example, which AFAIK need to be present on the system for the builds to work.

[artelse]

Has this been resolved and is it possible to download it somewhere? I think it would be great as it will draw in more users to this latest scantailor fork.

[FriedrichFroebel]

AFAIK not.

[zvezdochiot]

@artelse , https://github.com/ImageProcessing-ElectronicPublications/scantailor-advanced/releases

[FriedrichFroebel]

I would actually prefer an AppImage to be available as this does not require an installation. Besides this: The Debian builds do not work on Ubuntu 22.04 as libjpeg62-turbo cannot be found.

[pablogventura]

This was fixed in PR #108 (merge of 1.1.1 improvements) and follow-up PR #109 (Windows threshold overflow fix). Please close this issue.

[FriedrichFroebel]

Until there is a new release, I have no way to verify this. Thus I am not going to close this issue until then.

[pablogventura]

Where things stand (Linux binaries vs GitHub Releases)

The repository now has a tag-driven release workflow (.github/workflows/release.yml) that, on pushes to tags matching v*, builds:

• a .deb (build-deb.sh), and
• an AppImage (via linuxdeploy + linuxdeploy-plugin-qt),

then attaches both to a GitHub Release using softprops/action-gh-release (see the release job in that file). That directly targets the “artifacts expire / need to be logged in” pain from this issue—after a maintainer pushes a version tag, the assets should appear on the Releases page instead of only as short-lived CI artifacts.

@FriedrichFroebel’s point still applies: until a new release is actually tagged, it is hard to confirm in the wild that:

• the AppImage runs on typical distros (historical xcb plugin / bundling issues),
• .deb installs cleanly and declares reasonable Qt/runtime deps (metadata vs real Depends:),
• binaries avoid “Illegal instruction” on CPUs without the same SIMD baseline as the CI runner.

Calls for feedback

1. When the next v… tag is published, please download .deb + AppImage from Releases and report works / fails with distro + CPU (and full error text if any).
2. If RPM or other formats are still required, say so—this workflow is currently deb + AppImage only.
3. If CI artifacts on non-tag builds are still needed for PR testing, that can be a separate small enhancement (this issue is mainly about Releases).

Thanks @artelse and others for keeping visibility on this; a tagged release is the practical trigger to validate the pipeline end-to-end.

(Note: Merges like #108 / #109 improve the app itself; shipping Linux installers is chiefly about tagging + this release workflow + your test reports.)