Build scantailor on linux mint 20.1

[swan46]

I try to build scantailor on linux mint 20.1:

en@en-MS-7817:~/Letöltések/scantailor-master$ mkdir build en@en-MS-7817:~/Letöltések/scantailor-master$ cd build en@en-MS-7817:~/Letöltések/scantailor-master/build$ cmake .. -- Could NOT find Boost (missing: Boost_INCLUDE_DIR) qmake: could not exec '/usr/lib/qt5/bin/qmake': No such file or directory -- Found unsuitable Qt version "" from NOTFOUND CMake Error at CMakeLists.txt:124 (MESSAGE): Qt4 could not be found. If it's installed in a non-standard location, specify the path to qmake in QT_QMAKE_EXECUTABLE. You can do it in interactive mode (ccmake instead of cmake) or using -DVAR=VAL syntax. -- Configuring incomplete, errors occurred! See also "/home/en/Letöltések/scantailor-master/CMakeFiles/CMakeOutput.log". See also "/home/en/Letöltések/scantailor-master/CMakeFiles/CMakeError.log".

Could you please advise? Thank you in advance.

[trufanov-nok]

It's qt5, qt4 isn't supported in this fork.

In fact to make sure everything is on board it should be sudo apt install qtbase5-dev libqt5svg5-dev libtiff5-dev libjpeg8-dev libgcc1 libc6 libpng-dev libstdc++6 qttools5-dev libboost-dev libboost-test-dev cmake libcanberra-dev libopenjp2-7-dev

[swan46]

Thank you for the hints. Has anybody ever built scantailor with qt5? If yes, why can't scantailor be apt-get-ted, like for qt4 earlier?

[trufanov-nok]

Ok, now I got that you are talking about original ScanTailor, not this fork.

Original ST has Qt5 branch prepared long time ago, but it seems can't be just build without additional libboost-related changes. Also original ST project is archived by its maintainer, so it's read-only now. You better to try one of its forks, already ported to Qt5. Two most active is Universal (this one) and Advanced (more popular one). It will be much easier to build one of them from sources.

Try

sudo apt install qtbase5-dev libqt5svg5-dev libtiff5-dev libjpeg8-dev libgcc1 libc6 libpng-dev libstdc++6 qttools5-dev libboost-dev libboost-test-dev cmake libcanberra-dev libopenjp2-7-dev
cd /tmp
git clone https://github.com/trufanov-nok/scantailor-universal.git
cd scantailor-universal
mkdir build
cmake ..
make
sudo make install

[swan46]

Thank you for the hints above, I built now scantailor-universal successfully. I still do not understand, if scantailor is already ported to qt5, why is the executable not installable using apt-get? Why do I have to fight with trees and builds?

This is what I get: en@en-MS-7817:~$ sudo apt-get install scantailor [sudo] en jelszava:
Csomaglisták olvasása... Kész Függőségi fa építése
Állapotinformációk olvasása... Kész E: Ez a csomag nem található: scantailor

It can not find the packet scantailor. Do I do something incorrectly? Same with scantailor-universal and scantailor-advanced.

[swan46]

With your help I downloaded scantailor-universal, installed the libraries, you suggested, and built successfully scantailor-universal. Thanks a million! I still do not understand, why can't I get scantailor-universal using apt-get. Apt-get does not find the packet scantailor, scantailor-universal or scantailor advanced. Could you please advise, why that?

[trufanov-nok]

apt-get searches and downloads packages (not the apps, but packages that might contain app, related docs, shared libraries etc.) from the repositories. Repositories are servers, listed in /etc/apt/sources.list file. By default these are only servers maintained by maintainers of your system. For, ex Ubuntu have own repository servers, Debian have different repository servers (In fact Ubuntu takes a part of packages from Debian). The packages on these repositories are maintained by special guys, who are responsible for stable work of whole OS distributive system. They are responsible for fixing missing dependencies, some compatibility breaks, patching security issues in app sourcecode once they become public even author not fixed them yet, making sure the app isn't malware/backdoor etc. These guys aren't the authors of application. Author of application can't just build a package and submit it to repository of Ubuntu, for example. And 3rd party guy who's able to build scantailor with qt5 can't just publish this package in system repository too. So, to get into OS distribution system for some app it shall be chosen by this system repository maintainers. And system repository maintainers aren't keen to publish as much as possible software in their reps. Only most popular and stable products got there. As scantailor project is abandoned, its package was in the repository just till its dependencies was met. With removal of qt4 the scantailor package become unavailable for users of a newest OS versions too. And Universal and Advanced forks aren't popular (or stable in my case) enough to got repository maintainers attention.

So, how could prebuild package be distributed without system repositories?

1. One can set up its own repository server. Then add it to /etc/apt/sources.list, perform sudo apt-get update and all new packages become available for user. I have such server. In fact it's PPA (Personal Package Archive). My PPA is set up on Ubuntu's Launchpad project infrastructure. It's my personal repository there I'm responsible for quality of package. So if you would have Ubuntu based system (I'm using Kubuntu). You could perform:

   sudo add-apt-repository ppa:truf/scantailor-universal
   sudo apt-get update
   sudo apt install scantailor-universal

   But your system isn't Ubuntu-based and I pretty sure Ubuntu's launchpad PPA refuse to provide packages to Linux Mint. Frankly, Lunchpad isn't designed for 3rd party apps distribution at all, so I'm misusing it. Currently packages are available for Ubuntu-like 18.04+. That might be bypassed, but it's better to use option 2.

2. Just download the package file and install it with your hands. This assume that you're 100% trust the guy who maid the package, as there are binaries inside. In fact, downloading from someone PPA isn't safe too. So download the deb file and perform sudo dpkg -i package-file.deb. Later you may uninstall it with sudo apt remove package-name. But, of course you won't get notified about package updates by your system, as it doesn't now were you got this file. In case of latest available ST Universal you may perform:

   cd /tmp
   wget https://github.com/trufanov-nok/scantailor-universal/releases/download/0.2.12/scantailor-universal_0.2.12-0ubuntu1_amd64.deb
   sudo dpkg -i scantailor-universal_0.2.12-0ubuntu1_amd64.deb

But note, that I build and tested this package for Ubuntu. So won't be surprised if some dependencies won't be met or something else (icon not appears in menu). If scantailor-universal would be chosen for distribution via Linux Mint repository the Linux Mint guys would rebuild package from sources and make sure it works ok there. And I can't. Btw, the package dependencies are:

libc6 (>= 2.15), libcanberra0 (>= 0.30), libgcc1 (>= 1:3.0), libgomp1 (>= 4.9), libjpeg8 (>= 8c), libopenjp2-7 (>= 2.2.0), libpng16-16 (>= 1.6.2-1), libqt5core5a (>= 5.9.0~beta), libqt5gui5 (>= 5.7.0), libqt5widgets5 (>= 5.6.0~beta), libqt5xml5 (>= 5.4), libstdc++6 (>= 5.2), libtiff5 (>= 4.0.3)

So you better preliminary make sure they are in your system: sudo apt install libc6 libcanberra0 libgcc1 libgomp1 libjpeg8 libopenjp2-7 libpng16-16 libqt5core5a libqt5gui5 libqt5widgets5 libqt5xml5 libstdc++6 libtiff5

3. Build from sources.

[swan46]

Linux mint is ubuntu based, and method 1 did work. I wonder, why the installed file is much larger, than the one I built myself: ---------------------------------------------my built - size 4 MBytes en@en-MS-7817:~$ ldd /usr/local/bin/scantailor-universal | wc 46 180 3434 en@en-MS-7817:~$ nm /usr/local/bin/scantailor-universal | wc 10388 29234 839196 en@en-MS-7817:~$ ls -l /usr/local/bin/scantailor-universal -rwxr-xr-x 1 root root 4612704 jún 29 23:30 /usr/local/bin/scantailor-universal ----------------------------------------------installed --- size 10.5 MBytes en@en-MS-7817:~$ ldd /usr/bin/scantailor-universal | wc 46 180 3434 en@en-MS-7817:~$ nm /usr/bin/scantailor-universal | wc nm: /usr/bin/scantailor-universal: no symbols 0 0 0 en@en-MS-7817:~$ ls -l /usr/bin/scantailor-universal -rwxr-xr-x 1 root root 10508880 ápr 20 18:00 /usr/bin/scantailor-universal

Both work very well on my system, so now I am happy with scantailor. In my opinion you could add the apt-get and build information you gave me to scantailor.org file, it would save a lot of frustration for users. Also information about scantailor-advanced would be useful.

[trufanov-nok]

I wonder, why the installed file is much larger, than the one I built myself:

That's a good question, I should doublecheck. In fact that deb is built with pbuilder-dist in a clean chroot environment of Bionic (Ubuntu 18.04) system. And then package is just copied to the newer Ubuntu distributions inside PPA. So it supports 18.04+ systems as they are still backward compatible. Perhaps Ubuntu 18.04 had much older compiler, but twice bigger filesize.. I should check the compiler params.

[swan46]

en@en-MS-7817:~$ g++ --version g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 en@en-MS-7817:ld --version GNU ld (GNU Binutils for Ubuntu) 2.34

[trufanov-nok]

I wonder, why the installed file is much larger, than the one I built myself:

That was a bug which shall be now fixed with https://github.com/trufanov-nok/scantailor-universal/commit/d09e73a5b3f0309389eb140c62eaa29122baac17 The app during deb packaging was built without flags -DNDEBUG -O2 as builddeb was called with "None" build type. ST is using "Release" build type by default, but default mode is used when build type is empty or missing, not when it's equal to "None" string. So, now it should be fixed and binary will be smaller since next release.

[swan46]

I reinstalled using apt-get, and also used https://github.com/trufanov-nok/scantailor-universal/releases/download/0.2.12/scantailor-universal_0.2.12-0ubuntu1_amd64.deb The old big size. I tried https://github.com/trufanov-nok/scantailor-universal/releases/download/0.2.13/scantailor-universal_0.2.13-0ubuntu1_amd64.deb This does not exist.

[trufanov-nok]

Sorry, I incorrectly explained my thoughts. I don't want to rebuild existing debs - don't want to waste a time on this. But the next version (0.3.0) will have a proper binary size as the fix is already in a codebase.