graphviz in a recent Slackware current?

[Tuxedo]

Hello,

graphviz is a dependency for libinput and libinput is one of several
dependencies for QMapShack, a GIS program suitable for map data from GPS
devices etc.

However, using sbopkg it's not possible to complete the installaton of
graphviz on my Slackware 64 current for some reason, although I've succeded
in installing graphiviz on a regular 14.3 Slackware (64 with multilib).

The various errors in the sbopkg-build-log log are too long and illegible to
copy in here.

Has anyone succesfully installed graphviz in a recent Slackware current 64?
If so, from which source or package?

Many thanks,
Tuxedo

[Tuxedo]

Tuxedo wrote:

[...]

> succeded in installing graphiviz on a regular 14.3 Slackware (64 with
> multilib).

I meant 14.2 as there is of course no 14.3.

[Ars Ivci]

On Fri, 21 Sep 2018 00:24:11 +0200
Tuxedo <tux...@mailinator.com> wrote:

> Hello,
>
> graphviz is a dependency for libinput and libinput is one of several
> dependencies for QMapShack, a GIS program suitable for map data from GPS
> devices etc.
>
> However, using sbopkg it's not possible to complete the installaton of
> graphviz on my Slackware 64 current for some reason, although I've succeded
> in installing graphiviz on a regular 14.3 Slackware (64 with multilib).
>

Slackbuilds are designed to work on latest stable release, not current. Half the time they will build on current, though. Your best shot is compile the program from source, or if you're good at it, edit the Slackbuild for current.

--
peace,
t.

[Doug713705]

Le 2018-09-20, Tuxedo nous expliquait dans
alt.os.linux.slackware
(<po16uc$5ke$1...@solani.org>) :

> Hello,

Hi,

I use Graphviz and have it installed on my slackware-current and 14.2 as
well.

The version installed on the -current system is Graphviz 2.40.1
installed from the SlackBuild provided by Ponce:

https://github.com/Ponce/slackbuilds/wiki/configuring-the-current-repository-with-sbopkg

Beware with using SBO-git, it has some drawbacks and one of them is that
the total repo branch is updated before any SB compilation so your
local edited SB modifications get erased.

Note that on multilib systems some SlackBuilds need to be tweaked to
catch the good lib version. This could be done with the gcc -L switch
wich has to set to the library path (such as /usr/lib64 or /usr/lib)
depending on the desired architecture.

--
Je ne connaîtrai rien de tes habitudes
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43

[Tuxedo]

Doug713705 wrote:

[...]

> I use Graphviz and have it installed on my slackware-current and 14.2 as
> well.
>
> The version installed on the -current system is Graphviz 2.40.1
> installed from the SlackBuild provided by Ponce:
>
> https://github.com/Ponce/slackbuilds/wiki/configuring-the-current-repository-with-sbopkg
>
> Beware with using SBO-git, it has some drawbacks and one of them is that
> the total repo branch is updated before any SB compilation so your
> local edited SB modifications get erased.
>
> Note that on multilib systems some SlackBuilds need to be tweaked to
> catch the good lib version. This could be done with the gcc -L switch
> wich has to set to the library path (such as /usr/lib64 or /usr/lib)
> depending on the desired architecture.

Thanks for the feedback.

The reason have a Windows boot option is to easier install applications that
haven't been fixed to run in Linux yet.

In this case, before getting QMapShack working on the Slackware partition,
which requires graphviz, I reluctantly boot up Windows, as I found an easy-
to-install version at https://bitbucket.org/maproom/qmapshack/downloads/

On the new Slackware-current partition of the same laptop, I've used sbopkg
to launch 'sbopkg' and installed various packages via the usual menu
interface, which has with the exception of graphviz so far worked fine.

As far as I understand it, when launching sbopkg in this way, sbopkg
connects with repositories intented and tested for the 14.2 version of
Slackware, not necessarily my -current version.

I've not set up the multilib 32-bit convertor on the -current 64-bit system,
although I have done that on a previous Slackware 14.2 installation. I'm
hoping maybe this time I won't need to install any 32-bit only applications.

To try and install graphviz on my current Slackware 64, what exactly would
the lines of commands be? Its optional dependency gts installed fine via
sbopkg.

Many thanks,
Tuxedo

[Tuxedo]

Ars Ivci wrote:

[...]

> Slackbuilds are designed to work on latest stable release, not current.
> Half the time they will build on current, though. Your best shot is
> compile the program from source, or if you're good at it, edit the
> Slackbuild for current.

I'm not that good at compiling programs from source, as I'm not yet familiar
with the proceures.

Tuxedo

[root]

Tuxedo <tux...@mailinator.com> wrote:
>
> To try and install graphviz on my current Slackware 64, what exactly would
> the lines of commands be? Its optional dependency gts installed fine via
> sbopkg.

If you were to use slpkg the command would be:

slpkg -s slonly graphviz

to install graphviz-2.40.1-x86_64-1_slonly.txz

You have the following choices:
Packages with name matching [ graphviz ]

+==============================================================================
| Repository Package Size
+==============================================================================
conrad graphviz-2.41.20171026.1811-x86_64-10cf.txz 5260 K
sbo graphviz-2.40.1 0 K
sbo pygraphviz-1.3.1 0 K
sbo haskell-graphviz-2999.18.1.2 0 K
slonly graphviz-2.40.1-x86_64-1_slonly.txz 5172 K
slonly pygraphviz-1.3.1-x86_64-1_slonly.txz 96 K
slonly haskell-graphviz-2999.18.1.2-x86_64-1_slonly.txz 4920 K

Found summary
===============================================================================
Total found 7 packages in 3 repositories.


>
> Many thanks,
> Tuxedo
>

[root]

Tuxedo <tux...@mailinator.com> wrote:
> I'm not that good at compiling programs from source, as I'm not yet familiar
> with the proceures.

It is often as simple as this:

After downloading the source:

./configure
make
make install


>
> Tuxedo
>
>

[Ars Ivci]

There is nothing complicated about it. Get the source, usually a tarball or a zipped archive and extract it. Open a terminal and cd into the extracted directory. Read the files called README and/or INSTALL, they usually give instructions but usually it is as simple as typing 3 commands one after the other:
./configure (let it do its thing)
make (wait again)
make install (this last command as root).

Unlike most distros, Slackware carries complete build tools so if you installed everything, it will compile almost anything. You should refrain compiling really big apps like office programs, though; they will take hours if not days to compile.

As the time difference between stable and current increases, some Slackbuilds will inevitably fail due to missing, removed, renamed libraries in the current and you may not always find a Slackbuild for current.
--
peace,
t.

[Rich]

With slackbuilds the "procedures" are handled by the slackbuild script.

So even someone with no idea how to compile from source should be able
to use a slackbuild to compile something from source.

Now, creating a slackbuild, well, yes, there it is very helpful to be
familiar with the procedures for compiling from source.

[Tuxedo]

Thanks for the tip. I just had to install slpkg first, which I did via
sbopkg. Then in /etc/slpkg/slpkg.conf changed 'stable' to 'current':
RELEASE=current

And in /etc/slpkg/repositories.conf uncommented:
#slonly

And ran:
slpkg update

Thereafter I ran:

slpkg -s slonly graphviz

Output was:

Reading package lists... Done
Resolving dependencies... Done

The following packages will be automatically installed or upgraded
with new version:

+==============================================================================
| Package New Version Arch Build Repos Size
+==============================================================================
Installing:
graphviz 2.40.1 x86_64 2 slonly 5284 K

Installing summary
===============================================================================
Total 1 package.
1 package will be installed, 0 will be upgraded and 0 will be reinstalled.
Need to get 5.16 Mb of archives.
After this process, 16.95 Mb of additional disk space will be used.

Would you like to continue [y/N]?

....

Package graphviz-2.40.1 installed successfully

So that worked great!

Is slpkg better than sbopkg for installing most things on current, maybe
adding some of the additional repositories like in your setup?

Tuxedo

[Tuxedo]

Tuxedo wrote:

[...]

> Is slpkg better than sbopkg for installing most things on current, maybe
> adding some of the additional repositories like in your setup?
>
> Tuxedo

In proceeding with another dependency, I typed:

slpkg -s slonly ninja

The output was:

Reading package lists... Done
Resolving dependencies... Done

The following packages will be automatically installed or upgraded
with new version:

+==============================================================================
| Package New Version Arch Build Repos Size
+==============================================================================
Installing:

ninja-1.8.2 1.7.2 x86_64 1 slonly 88 K

Installing summary
===============================================================================
Total 1 package.

0 package will be installed, 1 will be upgraded and 0 will be reinstalled.
Need to get 88 Kb of archives.
After this process, 270 Kb of additional disk space will be used.

So instead of going forward to upgrade, I ran 'locate ninja' and found
various files on the system including /usr/doc/ninja-1.8.2/README

It appears that ninja-1.8.2 already exists on the system but that 1.7.2 is
referenced as a 'New Version' by slpkg. What can I assume by this?

Tuxedo

[root]

Tuxedo <tux...@mailinator.com> wrote:
>
> Package graphviz-2.40.1 installed successfully
>
> So that worked great!
>
> Is slpkg better than sbopkg for installing most things on current, maybe
> adding some of the additional repositories like in your setup?

When a package is available slpkg is by far the simplest way to go.
Not everything is available and you may have to fall back on other
nethods.

Every pre-built package was built from source using the aforementioned
./configure
make
make install

steps and you should familiarize yourself with this method as
it is the ultimate fallback. I should mention that the slpkg
repository SBo is simply Slackbuilds and you are taken
through the build from source.

One more thing. Too often the make procedure fails. When this
happens you will get an error message at the end. Google for
the error message to find possible solutions. It is also
useful to do:

config --help >config.help
and examine the file created. This will inform you of
available config options. You may be able to circumvent
a make failure by invoking the appropriate option. For
example, an error involving GTK may be avoided by
running config with something like this:

./config --disable-gtk

Consider it a blessing when slpkg gives you a functioning
package. If you don't like it you can always remove the
package.

>
> Tuxedo

[root]

I guess you can infer that slonly doesn't have the latest version
of ninja.

You should do:

slpkg -F package-name to see who has what. For slkg -F ninja I get:
Packages with name matching [ ninja ]

+==============================================================================
| Repository Package Size
+==============================================================================

alien ninja-1.7.2-x86_64-1alien.txz 84 K
connos ninja-1.8.2-x86_64-1_connos.tgz 104 K
ktown ninja-1.6.0-i486-1alien.txz 80 K
sbo ninja-ide-2.3 0 K
sbo ninja-1.8.2 0 K
sbo sqlninja-0.2.5 0 K
sbo ioninja-3.8.5 0 K
slonly ninja-ide-2.3-x86_64-1_slonly.txz 724 K
slonly ninja-1.8.2-x86_64-1_slonly.txz 88 K
slonly sqlninja-0.2.5-x86_64-1_slonly.txz 200 K
slonly ioninja-3.8.5-x86_64-1_slonly.txz 12268 K

Found summary
===============================================================================
Total found 11 packages in 5 repositories.

and I see the later version of ninja from slonly. Remember I am running
14.2-64, not current.



>
> Tuxedo
>
>

[Tuxedo]

Ars Ivci wrote:

[...]

> There is nothing complicated about it. Get the source, usually a tarball
> or a zipped archive and extract it. Open a terminal and cd into the
> extracted directory. Read the files called README and/or INSTALL, they
> usually give instructions but usually it is as simple as typing 3 commands
> one after the other: ./configure (let it do its thing) make (wait again)
> make install (this last command as root).
>
> Unlike most distros, Slackware carries complete build tools so if you
> installed everything, it will compile almost anything. You should refrain
> compiling really big apps like office programs, though; they will take
> hours if not days to compile.
>
> As the time difference between stable and current increases, some
> Slackbuilds will inevitably fail due to missing, removed, renamed
> libraries in the current and you may not always find a Slackbuild for
> current.

Thanks for these tips. I have indeed done these procedure before.

One dependency for the QMapShack applicaion is now qt5 and I opted for
trying to install via sbopkg while passing the PROPRIETARY_CODECS=yes

It was a very long install and at the end these errors were reported:

make[3]: *** [Makefile:20401: .obj/qsslcertificate_openssl.o] Error 1
make[3]: Leaving directory '/tmp/SBo/qt-everywhere-opensource-
src-5.7.1/qtbase/src/network'
make[2]: *** [Makefile:191: sub-network-make_first] Error 2
make[2]: Leaving directory '/tmp/SBo/qt-everywhere-opensource-
src-5.7.1/qtbase/src'
make[1]: *** [Makefile:47: sub-src-make_first] Error 2
make[1]: Leaving directory '/tmp/SBo/qt-everywhere-opensource-
src-5.7.1/qtbase'
make: *** [Makefile:78: module-qtbase-make_first] Error 2

qt5:
Would you like to continue processing the rest of the
queue or would you like to abort? If this failed
package is a dependency of another package in the queue
then it may not make sense to continue.

(Y)es to continue, (N)o to abort, (R)etry the build?: N

+++++++++++++++++++++++++++++++++++++++++++
SUMMARY LOG
Using the SBo repository for Slackware 14.2
Queue Process: Download, build, and install

qt5:
MD5SUM check for qt-everywhere-opensource-src-5.7.1.tar.xz ... OK
Error occurred with build. Please check the log.

-----

So I aborted the above installation in case it's not going to work. Or are
these errors non-critical, or would it perhaps be best to install qt5 via
slpkg or by ./configure and make install?

If running 'slpkg -s slonly qt5', the pre-intsall process suggest to handle
the dependencies libxkbcommon-0.7.1 (over 'New Version' also 0.7.1) and
libinput-1.11.3 (over 'New Version' 1.7.2), as follows:

Reading package lists... Done
Resolving dependencies... Done

The following packages will be automatically installed or upgraded
with new version:

+==============================================================================
| Package New Version Arch Build Repos Size
+==============================================================================
Installing:

qt5 5.7.1 x86_64 6 slonly 63244 K
Installing for dependencies:
libxkbcommon-0.7.1 0.7.1 x86_64 1 slonly 236 K
libinput-1.11.3 1.7.2 x86_64 1 slonly 492 K

Installing summary
===============================================================================
Total 3 packages.
1 package will be installed, 1 will be upgraded and 1 will be reinstalled.
Need to get 62.47 Mb of archives.
After this process, 276.04 Mb of additional disk space will be used.

Would you like to continue [y/N]?

----

I'm not sure if this will likely work and why exactly one same package needs
to be resintalled, so I didn't proceed yet.

Tuxedo

[Ars Ivci]

On Sat, 22 Sep 2018 01:08:51 +0200
Tuxedo <tux...@mailinator.com> wrote:

> Ars Ivci wrote:
>
> [...]
>
> > There is nothing complicated about it. Get the source, usually a tarball
> > or a zipped archive and extract it. Open a terminal and cd into the
> > extracted directory. Read the files called README and/or INSTALL, they
> > usually give instructions but usually it is as simple as typing 3 commands
> > one after the other: ./configure (let it do its thing) make (wait again)
> > make install (this last command as root).
> >

[...]

> One dependency for the QMapShack applicaion is now qt5 and I opted for
> trying to install via sbopkg while passing the PROPRIETARY_CODECS=yes
>
> It was a very long install and at the end these errors were reported:
>
> make[3]: *** [Makefile:20401: .obj/qsslcertificate_openssl.o] Error 1
> make[3]: Leaving directory '/tmp/SBo/qt-everywhere-opensource-
> src-5.7.1/qtbase/src/network'
> make[2]: *** [Makefile:191: sub-network-make_first] Error 2
> make[2]: Leaving directory '/tmp/SBo/qt-everywhere-opensource-
> src-5.7.1/qtbase/src'
> make[1]: *** [Makefile:47: sub-src-make_first] Error 2
> make[1]: Leaving directory '/tmp/SBo/qt-everywhere-opensource-
> src-5.7.1/qtbase'
> make: *** [Makefile:78: module-qtbase-make_first] Error 2
>
> qt5:
> Would you like to continue processing the rest of the
> queue or would you like to abort? If this failed
> package is a dependency of another package in the queue
> then it may not make sense to continue.
>
> (Y)es to continue, (N)o to abort, (R)etry the build?: N
>

I have to admit, I have never used slackpkg or anything similar with Slackware but always sticked to good old upgradepkg, installpkg or I compiled from source. Someone else mentioned before but let me repeat, slackbuilds are not packages, they are scripts to help you compile from source. It is best if you try to find a precompiled package for current first. If I'm not wrong Alien should have a qt5 package in his repositories.

--
peace,
t.

[Tuxedo]

Ars Ivci wrote:

[...]

> I have to admit, I have never used slackpkg or anything similar with
> Slackware but always sticked to good old upgradepkg, installpkg or I
> compiled from source. Someone else mentioned before but let me repeat,
> slackbuilds are not packages, they are scripts to help you compile from
> source. It is best if you try to find a precompiled package for current
> first. If I'm not wrong Alien should have a qt5 package in his
> repositories.

Thanks for the info. I found Alien's precompiled package which installed
easily by installpkg

Now with all the depedencies installed, I proceeded with QMapShack via
sbopkg. However, at the end of the sbopkg process there was an error:

-------------
CMake Error at /usr/lib64/cmake/Qt5WebKit/Qt5WebKitConfig.cmake:102
(find_package):
Could not find a package configuration file provided by "Qt5Network"
(requested version 5.9.1) with any of the following names:

Qt5NetworkConfig.cmake
qt5network-config.cmake

Add the installation prefix of "Qt5Network" to CMAKE_PREFIX_PATH or set
"Qt5Network_DIR" to a directory containing one of the above files. If
"Qt5Network" provides a separate development package or SDK, be sure it
has
been installed.
Call Stack (most recent call first):
/usr/lib64/cmake/Qt5WebKitWidgets/Qt5WebKitWidgetsConfig.cmake:102
(find_package)
CMakeLists.txt:132 (find_package)


-- Configuring incomplete, errors occurred!
See also "/tmp/SBo/qmapshack-1.11.1/build/CMakeFiles/CMakeOutput.log".
See also "/tmp/SBo/qmapshack-1.11.1/build/CMakeFiles/CMakeError.log".

qmapshack:

Would you like to continue processing the rest of the
queue or would you like to abort? If this failed
package is a dependency of another package in the queue
then it may not make sense to continue.

-------------


I did 'locate Qt5NetworkConfig.cmake' and found it in
/usr/lib/cmake/Qt5Network/

Still using sbopkg and before trying to reinstall a second time I selected
"Options - Edit Build Options/Flavours" where I added:

CMAKE_PREFIX_PATH=/usr/lib/cmake/Qt5Network/Qt5NetworkConfig.cmake

However, the same error was returned at the end of the install attempt. I
then tried entering:

Qt5Network_DIR=/usr/lib/cmake/Qt5Network/

I've installed Alien's qt5-webkit which is the version 5.9.1 from
http://www.slackware.com/~alien/slackbuilds/qt5-webkit/pkg64/current/ and
that appears to be what is requested by CMake.

Are the variable passed via sbopkg in the right way?

Tuxedo

PS: Requirements for QMapShack are:
gdal (installed via slpkg)
geos (installed via slpkg)
proj (intsalled via slpkg)
qt5-webkit (installpkg from Alien)
qt5 (installpkg from Alien)
libxkbcommon (installed 0.7.1 via slpkg)
libinput (exists in /usr/bin/)
libwacom (exists in /usr/share/)
meson (exists in /usr/bin/)
python3 (python 3.6 exists in /usr/bin/python3.6)
ninja (ninja-1-8-2 exist in /usr/bin)
graphviz (installed via slpkg) / optional dependency: gts (installed)
routino (installed via sbopkg)
quazip (installed via slpkg)

[Tuxedo]

root wrote:

[...]

Thanks for the above. I test the manual way. Anyway, the sbopkg version of
the final QMapShack application I'm trying to install is 1.11.1, while the
current version of the program is 1.12.0 which is available at
https://bitbucket.org/maproom/qmapshack/downloads/ ->
qmapshack-1.12.0.tar.gz

I could not find any precompiled Slackware package however.

Different install methods from the regular './configure, make and make
install' are detailed at https://bitbucket.org/maproom/qmapshack/overview

hg clone https://bitbucket.org/maproom/qmapshack QMapShack
mkdir build_QMapShack
cd build_QMapShack
ccmake ../QMapShack

ccmake fires up an interactive shell menu where I press 'c' to configure and
can see various generated path variables which seem to have auto-detected
the existence of necessary dependencies correctly. I then hit 'g' to
generate and exit and thereafter ran 'make':

bash-4.4# make

Scanning dependencies of target alg
[ 0%] Building CXX object
3rdparty/alglib/CMakeFiles/alg.dir/src/alglibinternal.cpp.o
[ 0%] Building CXX object
3rdparty/alglib/CMakeFiles/alg.dir/src/alglibmisc.cpp.o
[ 0%] Building CXX object 3rdparty/alglib/CMakeFiles/alg.dir/src/ap.cpp.o
/root/Desktop/QMapShack/3rdparty/alglib/src/ap.cpp: In function
?std::__cxx11::string alglib::arraytostring(const double*, alglib::ae_int_t,
int)?:
/root/Desktop/QMapShack/3rdparty/alglib/src/ap.cpp:8602:16: warning:
?sprintf? may write a terminating nul past the end of the destination [-
Wformat-overflow=]
if( sprintf(mask2, ",%s", mask1)>=(int)sizeof(mask2) )
~~~~~~~^~~~~~~~~~~~~~~~~~~~~
/root/Desktop/QMapShack/3rdparty/alglib/src/ap.cpp:8602:16: note: ?sprintf?
output between 2 and 65 bytes into a destination of size 64
[ 0%] Building CXX object
3rdparty/alglib/CMakeFiles/alg.dir/src/dataanalysis.cpp.o
[ 0%] Building CXX object
3rdparty/alglib/CMakeFiles/alg.dir/src/diffequations.cpp.o
[ 1%] Building CXX object
3rdparty/alglib/CMakeFiles/alg.dir/src/fasttransforms.cpp.o
[ 1%] Building CXX object
3rdparty/alglib/CMakeFiles/alg.dir/src/integration.cpp.o
[ 1%] Building CXX object
3rdparty/alglib/CMakeFiles/alg.dir/src/interpolation.cpp.o
[ 1%] Building CXX object
3rdparty/alglib/CMakeFiles/alg.dir/src/linalg.cpp.o
/root/Desktop/QMapShack/3rdparty/alglib/src/linalg.cpp: In function ?void
alglib_impl::rcond_cmatrixestimatenorm(alglib_impl::ae_int_t,
alglib_impl::ae_vector*, alglib_impl::ae_vector*, double*,
alglib_impl::ae_int_t*, alglib_impl::ae_vector*, alglib_impl::ae_vector*,
alglib_impl::ae_state*)?:
/root/Desktop/QMapShack/3rdparty/alglib/src/linalg.cpp:29511:25: warning:
?iter? may be used uninitialized in this function [-Wmaybe-uninitialized]
isave->ptr.p_int[1] = *iter;
~~~~~~~~~~~~~~~~~~~~^~~~~~~
/root/Desktop/QMapShack/3rdparty/alglib/src/linalg.cpp:29257:14: note:
?iter? was declared here
ae_int_t iter;
^~~~
/root/Desktop/QMapShack/3rdparty/alglib/src/linalg.cpp:29512:25: warning:
?j? may be used uninitialized in this function [-Wmaybe-uninitialized]
isave->ptr.p_int[2] = *j;
~~~~~~~~~~~~~~~~~~~~^~~~
/root/Desktop/QMapShack/3rdparty/alglib/src/linalg.cpp:29258:14: note: ?j?
was declared here
ae_int_t j;
^
/root/Desktop/QMapShack/3rdparty/alglib/src/linalg.cpp:29513:25: warning:
?jlast? may be used uninitialized in this function [-Wmaybe-uninitialized]
isave->ptr.p_int[3] = *jlast;
~~~~~~~~~~~~~~~~~~~~^~~~~~~~
/root/Desktop/QMapShack/3rdparty/alglib/src/linalg.cpp:29259:14: note:
?jlast? was declared here
ae_int_t jlast;
^~~~~
/root/Desktop/QMapShack/3rdparty/alglib/src/linalg.cpp:29515:28: warning:
?absxi? may be used uninitialized in this function [-Wmaybe-uninitialized]
rsave->ptr.p_double[0] = *absxi;
~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
/root/Desktop/QMapShack/3rdparty/alglib/src/linalg.cpp:29261:12: note:
?absxi? was declared here
double absxi;
^~~~~
/root/Desktop/QMapShack/3rdparty/alglib/src/linalg.cpp:29516:28: warning:
?altsgn? may be used uninitialized in this function [-Wmaybe-uninitialized]
rsave->ptr.p_double[1] = *altsgn;
~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
/root/Desktop/QMapShack/3rdparty/alglib/src/linalg.cpp:29262:12: note:
?altsgn? was declared here
double altsgn;
^~~~~~
/root/Desktop/QMapShack/3rdparty/alglib/src/linalg.cpp:29517:28: warning:
?estold? may be used uninitialized in this function [-Wmaybe-uninitialized]
rsave->ptr.p_double[2] = *estold;
~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
/root/Desktop/QMapShack/3rdparty/alglib/src/linalg.cpp:29263:12: note:
?estold? was declared here
double estold;
^~~~~~
/root/Desktop/QMapShack/3rdparty/alglib/src/linalg.cpp:29518:28: warning:
?temp? may be used uninitialized in this function [-Wmaybe-uninitialized]
rsave->ptr.p_double[3] = *temp;
~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
/root/Desktop/QMapShack/3rdparty/alglib/src/linalg.cpp:29265:12: note:
?temp? was declared here
double temp;
^~~~
[ 1%] Building CXX object
3rdparty/alglib/CMakeFiles/alg.dir/src/optimization.cpp.o
[ 2%] Building CXX object
3rdparty/alglib/CMakeFiles/alg.dir/src/solvers.cpp.o
[ 2%] Building CXX object
3rdparty/alglib/CMakeFiles/alg.dir/src/specialfunctions.cpp.o
[ 2%] Building CXX object
3rdparty/alglib/CMakeFiles/alg.dir/src/statistics.cpp.o
[ 2%] Linking CXX static library libalg.a
[ 2%] Built target alg
Scanning dependencies of target qmapshack_autogen
[ 3%] Automatic MOC for target qmapshack


However, at the above '[ 3%] Automatic MOC for target qmapshack' point the
process hangs.

At least the shell appears to have been up to nothing much for the last 30
minutes or so. Is this normal? Should I wait longer.

I hit Ctrl+C to interrupt the process.

Maybe the current snapshot of QMapShack is simply broken.

Maybe now I should clean up any mess that could have been caused by the
failed installation? Like an 'unmake'....?

If I run make again, it attempts to continue at the same point:

[ 2%] Build target alg
[ 3%] Automatic MOC for target qmapshack

... but it's still standing at 3% and not doing going further. What can I
try next?

Tuxedo

[Tuxedo]

Tuxedo wrote:

[...]

>
> Maybe now I should clean up any mess that could have been caused by the
> failed installation? Like an 'unmake'....?

make clean (I guess)

[...]

Now I can re-run the make procedure but it still hangs at 3%. I guess
something in the Makefile has to be fixed or maybe I must wait for a future
version of QMapShack and try again.

> Tuxedo

[root]

Tuxedo <tux...@mailinator.com> wrote:

>
> ... but it's still standing at 3% and not doing going further. What can I
> try next?

I didn't follow all the details of your post. There is no unmake,
instead you use
make clean

However, if you follow this by a repeat of make you will get
the same result. The only thing that will change the result
is to change the ./configure step.



>
> Tuxedo
>

[root]

If the make process hangs without any error message then you could
try googling for: make process hangs qmapshack and pray for
a solution.
>

[Tuxedo]

root wrote:

[...]

> I didn't follow all the details of your post. There is no unmake,
> instead you use
> make clean
>
> However, if you follow this by a repeat of make you will get
> the same result. The only thing that will change the result
> is to change the ./configure step.

I did some searches but couldn't find any answers. There are just too many
configure options and I don't understand half of them. Sooner or later I'm
sure there will be an updated QMapShack Slackware package for current.
Meanwhile, I'll pray I won't have to boot Windows too often :-)

Tuxedo

[Doug713705]

Le 2018-09-22, Tuxedo nous expliquait dans
alt.os.linux.slackware
(<po6ft5$nd3$1...@solani.org>) :

[SNIP details]

> Scanning dependencies of target qmapshack_autogen
> [ 3%] Automatic MOC for target qmapshack
>
> However, at the above '[ 3%] Automatic MOC for target qmapshack' point the
> process hangs.
>
> At least the shell appears to have been up to nothing much for the last 30
> minutes or so. Is this normal? Should I wait longer.

Probably yes !

You should monitor your CPU usage and look at its activity.

Unless you have an explicit error the compilation is very likely still running.

If you can see significative CPU activity while the compilation *seems*
hanged then the compilation is still running.

Just wait untill an explicit error or compilation's end without hitting
Ctrl+C.

--
Je ne connaîtrai rien de tes habitudes

Il se peut même que tu sois décédée

[Tuxedo]

Doug713705 wrote:

> Le 2018-09-22, Tuxedo nous expliquait dans
> alt.os.linux.slackware
> (<po6ft5$nd3$1...@solani.org>) :
>
> [SNIP details]
>
>> Scanning dependencies of target qmapshack_autogen
>> [ 3%] Automatic MOC for target qmapshack
>>
>> However, at the above '[ 3%] Automatic MOC for target qmapshack' point
>> the process hangs.
>>
>> At least the shell appears to have been up to nothing much for the last
>> 30 minutes or so. Is this normal? Should I wait longer.
>
> Probably yes !
>
> You should monitor your CPU usage and look at its activity.
>
> Unless you have an explicit error the compilation is very likely still
> running.
>
> If you can see significative CPU activity while the compilation *seems*
> hanged then the compilation is still running.
>
> Just wait untill an explicit error or compilation's end without hitting
> Ctrl+C.
>

Good to know. However, in this case, CPU activity drops as soon as the
compilation process comes to the '[ 3%] Automatic MOC for target qmapshack'
point. And without any kind of error message, it's hard to guess a cause.

After about 40 minutes of inactivity I did Crtl+C again.

I've installed QMapShack on a previous 14.2 Slackware but it was also a
previous QMapShack (1.11.1) version. The version I'm trying to install is
1.12.0 (2018-09-03).

So to test an earlier version on the new and current system, I download
qmapshack.tar.gz and qmapshack-1.11.1.tar.gz from
https://slackbuilds.org/repository/14.2/gis/qmapshack and ran:
./qmapshack.SlackBuild

... but the same compilation error as in sbopkg happens:

CMake Error at /usr/lib64/cmake/Qt5WebKit/Qt5WebKitConfig.cmake:102
(find_package):
Could not find a package configuration file provided by "Qt5Network"
(requested version 5.9.1) with any of the following names:

Qt5NetworkConfig.cmake
qt5network-config.cmake

Add the installation prefix of "Qt5Network" to CMAKE_PREFIX_PATH or set
"Qt5Network_DIR" to a directory containing one of the above files. If
"Qt5Network" provides a separate development package or SDK, be sure it has
been installed.
Call Stack (most recent call first):
/usr/lib64/cmake/Qt5WebKitWidgets/Qt5WebKitWidgetsConfig.cmake:102
(find_package)
CMakeLists.txt:132 (find_package)


-- Configuring incomplete, errors occurred!
See also "/tmp/SBo/qmapshack-1.11.1/build/CMakeFiles/CMakeOutput.log".
See also "/tmp/SBo/qmapshack-1.11.1/build/CMakeFiles/CMakeError.log".

--------------

I have a Qt5NetworkConfig.cmake file on the new system in
/usr/lib/cmake/Qt5Network/Qt5NetworkConfig.cmake

As far as I understand I should add the variable in qmapshack.SlackBuild but
exactly where? Maybe at the top, as in:

#!/bin/sh
# ...

PRGNAM=qmapshack
VERSION=${VERSION:-1.11.1}
BUILD=${BUILD:-1}
TAG=${TAG:-_SBo}
Qt5Network_DIR=/usr/lib/cmake/Qt5Network
....


I reran ./qmapshack.SlackBuild against the above but which is resulting in
the same error.

Or adding the Qt5Network_DIR path in the "Edit Build Options/Flavors" of
sbopkg resulted in the same.

Did I add the Qt5Network_DIR parameter in the right way?

What else is not quite clear to me is the output:

"If Qt5Network" provides a separate development package or SDK, be sure it
has been installed."

Has anyone made QMapShack run on Slackware current with either QMapShack
version 1.11.1 or 1.12.0.

Maybe I need to reinstall some of the dependencies with different and
perhapos newer versions.

Many thanks,
Tuxedo

[Doug713705]

Le 2018-09-23, Tuxedo nous expliquait dans
alt.os.linux.slackware
(<po8ikm$5t7$1...@solani.org>) :

> As far as I understand I should add the variable in qmapshack.SlackBuild but
> exactly where? Maybe at the top, as in:
>
> #!/bin/sh
> # ...
>
> PRGNAM=qmapshack
> VERSION=${VERSION:-1.11.1}
> BUILD=${BUILD:-1}
> TAG=${TAG:-_SBo}
> Qt5Network_DIR=/usr/lib/cmake/Qt5Network
> ....
>
>
> I reran ./qmapshack.SlackBuild against the above but which is resulting in
> the same error.

It looks a bit more complicated.
The error message is printed by the compiler, not the Slackbuild script.
Adding variables to the SB script will not change anything.

My guess is you don't have the needed version of Qt5 or maybe you don't
even have installed qt5.

Here on my Slackware-current I have qt5-5.11.0 wich provides Qt5Network files.
Note that I may have tweaked the info and SB files to have such a qt5 version (I didn't
checked but I believe SBo doesn't provides qt5 above 5.9).

$ tar -tvzf /var/www/pkg.redatomik.org/current/qt5-5.11.0-x86_64-1_SBo.tgz | grep Qt5Network
-rw-r--r-- root/root 263 2018-06-01 14:18 usr/lib64/pkgconfig/Qt5Network.pc
-rw-r--r-- root/root 294 2018-06-01 14:19 usr/lib64/pkgconfig/Qt5NetworkAuth.pc
drwxr-xr-x root/root 0 2018-06-01 14:19 usr/lib64/cmake/Qt5Network/
-rw-r--r-- root/root 6467 2018-06-01 09:39 usr/lib64/cmake/Qt5Network/Qt5NetworkConfig.cmake
-rw-r--r-- root/root 288 2018-06-01 09:39 usr/lib64/cmake/Qt5Network/Qt5NetworkConfigVersion.cmake
-rw-r--r-- root/root 212 2018-06-01 09:59 usr/lib64/cmake/Qt5Network/Qt5Network_QGenericEnginePlugin.cmake
-rw-r--r-- root/root 212 2018-06-01 09:59 usr/lib64/cmake/Qt5Network/Qt5Network_QConnmanEnginePlugin.cmake
-rw-r--r-- root/root 228 2018-06-01 09:59 usr/lib64/cmake/Qt5Network/Qt5Network_QNetworkManagerEnginePlugin.cmake
drwxr-xr-x root/root 0 2018-06-01 14:19 usr/lib64/cmake/Qt5NetworkAuth/
-rw-r--r-- root/root 6848 2018-06-01 10:03 usr/lib64/cmake/Qt5NetworkAuth/Qt5NetworkAuthConfig.cmake
-rw-r--r-- root/root 288 2018-06-01 10:03 usr/lib64/cmake/Qt5NetworkAuth/Qt5NetworkAuthConfigVersion.cmake
-rwxr-xr-x root/root 1625712 2018-06-01 14:20 usr/lib64/libQt5Network.so.5.11.0
-rw-r--r-- root/root 1046 2018-06-01 14:20 usr/lib64/libQt5Network.prl
-rw-r--r-- root/root 659 2018-06-01 14:18 usr/lib64/libQt5Network.la
-rwxr-xr-x root/root 237040 2018-06-01 14:20 usr/lib64/libQt5NetworkAuth.so.5.11.0
-rw-r--r-- root/root 1042 2018-06-01 14:20 usr/lib64/libQt5NetworkAuth.prl
-rw-r--r-- root/root 700 2018-06-01 14:19 usr/lib64/libQt5NetworkAuth.la

[Tuxedo]

Thanks, trying to figure which versions of various libraries are installed
sometimes becomes a bit of a mystery. But in case of libinput I could run:
libinput --version

... which returned 1.11.3

You are right, in SBo qt5 is 5.7.1 (while QMapShack requires 5.8)

So I run slpkg - slonly qt5

It sa it's 'Installing: qt5-5.11' and replacing dependency libxkcommon-0.7.1
with the same, just reinstalling it I guess, and that it's installing
libinput 1.11.3 (but with New Version listed as 1.7.2).

But in the end it appears that libinput was downgraded to 1.7.3 and the
command 'libinput --version' now command returns 'command not found'. I
appear to have downgraded it.

And running 'lpkg -s slonly qt5' now returns the screen:

Reading package lists... Done
Resolving dependencies... Done

The following packages will be automatically installed or upgraded with new
version:

+==============================================================================
| Package New Version Arch Build Repos Size
+==============================================================================
Installing:

qt5-5.7.1 5.7.1 x86_64 6 slonly 63244 K

Installing for dependencies:
libxkbcommon-0.7.1 0.7.1 x86_64 1 slonly 236 K

libinput-1.7.2 1.7.2 x86_64 1 slonly 492 K

Installing summary
===============================================================================
Total 3 packages.
0 package will be installed, 0 will be upgraded and 3 will be reinstalled.
Need to get 62.47 Mb of archives.
After this process, 276.04 Mb of additional disk space will be used.
--------

I've been mixing up the columns, misreading "Installing:
Package...". thinking that's what's being installed. Anything in the Package
column is obviously the old version, which I can't rememmber what it was
before, but I think later than 5.8. Now I have qt5-5.7.1.

When running ccmake ../QMapShack and try to configure it returns the error:
CMake Error at CMakeLists.txt:146 (message):
You need at least qt5.8 or newer.

This error did not happen before, even when the compilation hanged.

In /etc/slpkg/slpkg.conf I have:
RELEASE=current

And in /etc/slpkg/repositories.conf so far I uncommended only:

slonly

Looking at this file again it states 'conrad' must be used for current, so I
uncomment conrad and ran 'spkg update' and 'slpkg -s conrad qt5' but this
found nothing new.

I thereafter uncommented 'alien' out of curiousity and ran 'slpkg -s alien
qt5' which lists 'New Version' in the 'Package' table as 5.11.2 for qt5 and
libxkbcommon as 0.8.2, and throws in another depencency named OpenAL 1.19.9.
So I complete this installation.

I then return to the 'ccmake ../QMapShack' and 'make' procedure and the
installation proceeds further! It's been combiling for the last 30 minutes
and is still busy compiling with CPU running high....

Tuxedo

[Tuxedo]

Tuxedo wrote:

> I then return to the 'ccmake ../QMapShack' and 'make' procedure and the
> installation proceeds further! It's been combiling for the last 30 minutes
> and is still busy compiling with CPU running high....

But compilation stopped this time much later with an error:
[...]
collect2: error: ld returned 1 exit status
make[2]: *** [src/qmapshack/CMakeFiles/qmapshack.dir/build.make:5633:
bin/qmapshack] Error 1
make[1]: *** [CMakeFiles/Makefile2:180:
src/qmapshack/CMakeFiles/qmapshack.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

Maybe something else needs to be updated as well.

Tuxedo

[Ars Ivci]

I forgot previous messages in the thread but did you give a try for following 14.2 package:
https://slackware.pkgs.org/14.2/slackonly-x86_64/qmapshack-1.11.1-x86_64-1_slonly.txz.html

Note the dependencies and verify you have them.
--
peace,
t.

[Doug713705]

Le 2018-09-24, Tuxedo nous expliquait dans
alt.os.linux.slackware
(<poa07l$1t2$1...@solani.org>) :

You shortened the error message too much so we can't tell you anything.

In my opinion you should read about shared libraries and how the system
works with it.

It would help you to have a better understanding of what you are doing.

Also, avoiding the use of multiple package managers on the same system
is usualy a good idea.

IMHO slackpkg for official packages and sbopkg for slackbuilds.org are
very enough to suit all needs.

In most cases if you're looking for a lib version not provided by
slackbuilds.org, you just need to edit the info and the SlackBuild
files to make sbopkg build the wanted version.

sbopkg provides a "custom" menu allowing to modify those files.

Good luck.

[Tuxedo]

Doug713705 wrote:

[...]

> You shortened the error message too much so we can't tell you anything.
>
> In my opinion you should read about shared libraries and how the system
> works with it.
>
> It would help you to have a better understanding of what you are doing.
>
> Also, avoiding the use of multiple package managers on the same system
> is usualy a good idea.
>
> IMHO slackpkg for official packages and sbopkg for slackbuilds.org are
> very enough to suit all needs.
>
> In most cases if you're looking for a lib version not provided by
> slackbuilds.org, you just need to edit the info and the SlackBuild
> files to make sbopkg build the wanted version.
>
> sbopkg provides a "custom" menu allowing to modify those files.
>
> Good luck.

The above error were all there was but countless lines of output appeared
before the error which did not appear to be errors.

Anyhow, the QMapShack version which Ars Ivci just posted a link to at
https://slackware.pkgs.org/14.2/slackonly-x86_64/qmapshack-1.11.1-x86_64-1_slonly.txz.html installs by running:
installpkg qmapshack-1.11.1-x86_64-1_slonly.txz
or:
upgradepkg --install-new qmapshack-1.11.1-x86_64-1_slonly.txz

However, running 'qmapshack' thereafter returns:
error while loading shared libraries libproj.so.13: cannot open shared
object file: No such file or directory

While I can't find a 'libproj' via sbopkg or slpkg, there is a
/usr/lib64/libproj.so file on the system.

Using upgradepkg or installpkg, is it possible to pass the necessary
parameters for the missing library? Or when running qmapshack?

Or would the source need to be modified and repackaged as a .txz and run
upgradepkg?

Thanks for any ideas.

Tuxedo

[Doug713705]

Le 2018-09-24, Tuxedo nous expliquait dans
alt.os.linux.slackware

(<poa6se$6g6$1...@solani.org>) :

qmapshack is complaining about a bad lib version number and it's not a
surprise because you installed a qmapshack binary package without any
knowledge of its dependency tree.

Some other dependencies may also be in a wrong version or even missing.

> While I can't find a 'libproj' via sbopkg or slpkg, there is a
> /usr/lib64/libproj.so file on the system.

You need to know which package provides and upgrade it to the *expected
version*.

The package is "proj" which is provided by SlackBuilds.org.

proj will gives you /usr/lib64/libproj.so.13 wich is what qmapshack is looking for.

> Using upgradepkg or installpkg, is it possible to pass the necessary
> parameters for the missing library? Or when running qmapshack?

Short answer: No

Slackware is not Debian or CentOS. There is no dependency resolution.

You need to understand what you're trying to achieve (installing a
package with all its dependencies) and then all answers will be clear to you.

You might lose many times trying to by-pass this advice but it is all you
need now.

> Or would the source need to be modified and repackaged as a .txz and run
> upgradepkg?

No, you need to find out all dependencies of qmapshack and be sure
they are all satisfied before installing or using qmapshack.

The is *no* other solution with Slackware.

[Doug713705]

Le 2018-09-24, Tuxedo nous expliquait dans
alt.os.linux.slackware

(<poa6se$6g6$1...@solani.org>) :

qmapshack is complaining about a bad lib version number and it's not a
surprise because you installed a qmapshack binary package without any
knowledge of its dependency tree.

Some other dependencies may also be in a wrong version or even missing.

> While I can't find a 'libproj' via sbopkg or slpkg, there is a
> /usr/lib64/libproj.so file on the system.

You need to know which package provides and upgrade it to the *expected
version*.

The package is "proj" which is provided by SlackBuilds.org.

proj will gives you /usr/lib64/libproj.so.13 wich is what qmapshack is looking for.

> Using upgradepkg or installpkg, is it possible to pass the necessary
> parameters for the missing library? Or when running qmapshack?

Short answer: No

Slackware is not Debian or CentOS. There is no dependency resolution.

You need to understand what you're trying to achieve (installing a
package with all its dependencies) and then all answers will be clear to you.

You might lose many times trying to by-pass this advice but it is all you
need now.

> Or would the source need to be modified and repackaged as a .txz and run
> upgradepkg?

No, you need to find out all dependencies of qmapshack and be sure
they are all satisfied before installing or using qmapshack.

There is *no* other solution with Slackware.

[Giovanni]

On 09/24/2018 10:18 AM, Tuxedo wrote:

> However, running 'qmapshack' thereafter returns: error while loading
> shared libraries libproj.so.13: cannot open shared object file: No
> such file or directory

Try to run 'ldd /usr/bin/qmapshack' (assuming qmapshack executable is in
/usr/bin) and you'll get a list of required libraries.

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
< http://giovanni.homelinux.net/ >

[root]

Tuxedo <tux...@mailinator.com> wrote:
>
>
> You are right, in SBo qt5 is 5.7.1 (while QMapShack requires 5.8)
>
> So I run slpkg - slonly qt5

You should run:

slpkg -F qt5

to find if any repository has a version later than 5.7.1

I find no repository has 5.8 for 14.2.

>

[Tuxedo]

Giovanni wrote:

[...]

> Try to run 'ldd /usr/bin/qmapshack' (assuming qmapshack executable is in
> /usr/bin) and you'll get a list of required libraries.

Thanks for this neat trick!

bash 4.4$ ldd /usr/bin/qmapshack |grep "not found"
libproj.so.13 => not found
libpoppler.so.68 => not found
libfreexl.so.1 => not found
libxerces-c-3.1.so => not found
libicui18n.so.56 => not found
libicuuc.so.56 => not found
libicudata.so.56 => not found
libnetcdf.so.11 => not found
libhdf5_hl.so.10 => not found
libhdf5.so.10 => not found
libmfhdf.so.0 => not found
libdf.so.0 => not found
libpq.so.5 => not found

It should get me on the right track to install or upgrade what's missing :-)

Tuxedo

[Tuxedo]

Doug713705 wrote:

[...]

> There is *no* other solution with Slackware.

It's probably better than having some package manager trying to resolve
dependencies automatically but likely breaking a perfectly working system.

Tuxedo

[Doug713705]

Le 2018-09-24, Tuxedo nous expliquait dans
alt.os.linux.slackware

(<poasd7$lga$2...@solani.org>) :

Sure it is :)
But it needs to understand what is going on under the under the hood.

--
C'est juste une fille un peu perverse
Qui me plante des couteaux dans les fesses
Et qui me coince dans les urinoirs
En sortant sa lame de rasoir.
-- H.F. Thiéfaine, Groupie 89 turbo 6

[Tuxedo]

root wrote:

[...]

> You should run:
>
> slpkg -F qt5
>
> to find if any repository has a version later than 5.7.1
>
> I find no repository has 5.8 for 14.2.

Thanks for the 'slpkg -F xyz' tip.

Meanwhile, I found qt5-5.11.2 at
http://www.slackware.com/~alien/slackbuilds/qt5/pkg/current/ and installed
it by installpkg:

While trying to solve each dependency to make QMapShack compile using
qmapshack-1.12.0.tar.gz from
https://bitbucket.org/maproom/qmapshack/downloads/ the make procedure
appears to fail starting with a request for libproj.so.12:

/usr/bin/ld: warning: libproj.so.12, needed by /usr/lib64/gcc/x86_64-
slackware-linux/8.2.0/../../../../lib64/libgdal.so, not found (try using -
rpath or -rpath-link)

The complete output of the failed make is at https://pastebin.com/hUskhs0v

The error above is on line 369, followed by various requests for libraries
which do however exist on the system.

I looked into Proj and as far as I understand libproj.so.12 comes with
proj-4.9.3-x86_64-1_slonly.txz while my Slackware current now has a newer
version of Proj.

I also installed proj-4.9.3-x86_64-1_slonly.txz since the program requests
it, resulting in a /usr/lib/libproj.so.12 file as well as a
/usr/lib64/libproj.so.13

I don't have multilibs set up on my 64 current installation, but as far as I
understand, QMapShack is not a 32-bit compatible application anyway.

Before I ran 'make' I did 'ccmake ../QMapShack' against the sources from
https://bitbucket.org/maproom/qmapshack/downloads/ following the procedure
at https://bitbucket.org/maproom/qmapshack/overview

These were the autogenerated variables (which can modified) or added to:

-----------------------------------------------------------

IN_INSTALL_DIR */usr/local/bin
BUILD_FOR_LOCAL_SYSTEM *OFF
BUILD_QMAPSHACK *ON
BUILD_QMAPTOOL *ON
CMAKE_BUILD_TYPE *RelWithDebInfo
CMAKE_INSTALL_PREFIX */usr/local
DATA_INSTALL_DIR */usr/local/share
DATA_INSTALL_PREFIX */usr/local/share
EXEC_INSTALL_PREFIX */usr/local
GDAL_INCLUDE_DIR */usr/include
GDAL_LIBRARY */usr/lib64/libgdal.so
HTML_INSTALL_DIR */usr/local/share/doc/HTML
ICON_INSTALL_DIR */usr/local/share/icons
INCLUDE_INSTALL_DIR */usr/local/include
INFO_INSTALL_DIR */usr/local/share/info
KEEP_OLD_TRANSLATIONS *ON
LIBEXEC_INSTALL_DIR */usr/local/libexec
LIB_INSTALL_DIR */usr/local/lib
LIB_SUFFIX *
LOCALE_INSTALL_DIR */usr/local/share/locale
MAN_INSTALL_DIR */usr/local/share/man
PLUGIN_INSTALL_DIR */usr/local/lib/qmapshack
Qt5Core_DIR */usr/lib64/cmake/Qt5Core
Qt5DBus_DIR */usr/lib64/cmake/Qt5DBus
Qt5Gui_DIR */usr/lib64/cmake/Qt5Gui
Qt5LinguistTools_DIR */usr/lib64/cmake/Qt5LinguistTools
Qt5Network_DIR */usr/lib64/cmake/Qt5Network
Qt5Positioning_DIR */usr/lib64/cmake/Qt5Positioning
Qt5PrintSupport_DIR */usr/lib64/cmake/Qt5PrintSupport
Qt5Qml_DIR */usr/lib64/cmake/Qt5Qml
Qt5Quick_DIR */usr/lib64/cmake/Qt5Quick
Qt5Sql_DIR */usr/lib64/cmake/Qt5Sql
Qt5UiTools_DIR */usr/lib64/cmake/Qt5UiTools
Qt5WebChannel_DIR */usr/lib64/cmake/Qt5WebChannel
Qt5WebEngineCore_DIR */usr/lib64/cmake/Qt5WebEngineCore
Qt5WebEngineWidgets_DIR */usr/lib64/cmake/Qt5WebEngineWidgets
Qt5Widgets_DIR */usr/lib64/cmake/Qt5Widgets
Qt5Xml_DIR */usr/lib64/cmake/Qt5Xml
SBIN_INSTALL_DIR */usr/local/sbin
SHARE_INSTALL_PREFIX */usr/local/share
SOUND_INSTALL_DIR */usr/local/share/sounds
SYSCONF_INSTALL_DIR */usr/local/etc
UPDATE_TRANSLATIONS *OFF
USE_QT5DBus *ON
XDG_APPS_DIR */usr/local/share/applications
XDG_DIRECTORY_DIR */usr/local/share/desktop-directories

Press [enter] to edit option Press [d] to delete an entry
CMake Version 3.12.1
Press [c] to configure Press [g] to generate and exit
Press [h] for help Press [q] to quit without generating
Press [t] to toggle advanced mode (Currently Off)
------------------------------------------------------------

I pressed 'g' and thereafter ran 'make' but the compilation didn't work.

I can install an older version of QMapShack from a precompiled package by:
installpkg qmapshack-1.11.1-x86_64-1_slonly.txz
...
Executing install script...
Package qmapshack-1.11.1-x86_64-1_slonly.txz installed.


But when running 'qmapshack' after, there's the following error relating to
libproj.so.12: ...

qmapshack: error while loading shared libraries: libproj.so.12: cannot open

shared object file: No such file or directory

... but the file exist on the system in /usr/lib/libproj.so.12

While still having qmapshack-1.11.1 installed, doing: ...

ldd /usr/bin/qmapshack |grep "not found"

... returns:
libproj.so.12 => not found
libpoppler.so.68 => not found

libxerces-c-3.1.so => not found
libicui18n.so.56 => not found
libicuuc.so.56 => not found
libicudata.so.56 => not found

libpq.so.5 => not found

In case anyone has QMapShack installed on a Slackware current 64, how did
you go about installing it? I guess it can be a very complex installation
since it's a GIS program which utilises many libraries and toolkits.

At the same time, on previous 14.2 Slackware 64 stable, installing
QMapShack-1.11.1 was breeze, but that was a different system with a
different collection of installed libraries including multilib (in case that
may make some difference after all.)

Many thanks any random advise!

Tuxedo

Dependencies installed including optional ones in the new Slackware 64
current:

gdal (installed via slpkg)
geos (installed via slpkg)
proj (intsalled via slpkg)

qt5-webkit (installed version from
http://www.slackware.com/~alien/slackbuilds/qt5-webkit/pkg64/current/)
qt5 (sbopkg did not work but installpkg with version from
http://www.slackware.com/~alien/slackbuilds/qt5/pkg/current/ did)

libxkbcommon (installed 0.7.1 via slpkg)

libinput (exists in /usr/bin/libinput)
libwacom (exists in /usr/share/libwacom)
meson (exists in /usr/bin/meson)

python3 (python 3.6 exists in /usr/bin/python3.6)

ninja (ninja-1-8-2 appears to exist although slpkg wants to upgrade and list
1.7.2 as a new version!?)
graphviz (install via slpkg) / optional dependency: gts (installed)
python-evdev (installed)
pyudev (installed)

routino (installed via sbopkg)
quazip (installed via slpkg)

updated 'proj' to version 5.20
installed poppler-qt5 via sbo (poppler on system was for qt4)
installed freexl via slpkg
installed xerces-c 3.2.0 via sbo
libicui (/usr/lib64/libicui18n.so) but what is icu4c-61.1?
installed netcdf (4.4.1.1) via slpkg which also installed the hdf5
(1.1.15_patch1) dependency
hdf4 exists in sbo but with note on top that netcdf is installed
installed htf (4.2.13) via slpkg
libdf.so exists in /usr/lib64/libdf.so

[Ars Ivci]

On Tue, 25 Sep 2018 19:22:55 +0200
Tuxedo <tux...@mailinator.com> wrote:

I think some of deps you installed were 32-bit and that's why you're having problems.

> root wrote:
>
> [...]
>
> > You should run:
> >
> > slpkg -F qt5
> >
> > to find if any repository has a version later than 5.7.1
> >
> > I find no repository has 5.8 for 14.2.
>
> Thanks for the 'slpkg -F xyz' tip.
>
> Meanwhile, I found qt5-5.11.2 at
> http://www.slackware.com/~alien/slackbuilds/qt5/pkg/current/ and installed
> it by installpkg:
>

^^^
This is a 32-bit package; it should have been .../qt5/pkg64/...

[...]

> qt5 (sbopkg did not work but installpkg with version from
> http://www.slackware.com/~alien/slackbuilds/qt5/pkg/current/ did)

^^^
Another 32-bit package.

I do not know anything about qmaps, is it a 32-bit app or does it require anything 32-bit? Maybe someone who used it before can shed some light.

If I were you, I'd clean everyhing, take a deep breath and start over with fresh eyes and always sticking to 64-bit binaries.

--
peace,
t.

[Henrik Carlqvist]

On Tue, 25 Sep 2018 19:22:55 +0200, Tuxedo wrote:
> Meanwhile, I found qt5-5.11.2 at
> http://www.slackware.com/~alien/slackbuilds/qt5/pkg/current/ and
> installed it by installpkg:

> I also installed proj-4.9.3-x86_64-1_slonly.txz since the program
> requests it, resulting in a /usr/lib/libproj.so.12 file as well as a
> /usr/lib64/libproj.so.13

> qmapshack: error while loading shared libraries: libproj.so.12: cannot
> open shared object file: No such file or directory

So you start by a unstable pre-beta version of slackware, add a mix of
dynamic libraries from different sources and then wonder why it doesn't
work?

> ... but the file exist on the system in /usr/lib/libproj.so.12

No, those dynamic library files belwo /usr/lib are supposed to be 32 bit
library files for 32 bit applications, useful for multilib installations.
64 bit applications search for their dynamic library files in /usr/lib64.

regards Henrik

[Doug713705]

Le 2018-09-25, Tuxedo nous expliquait dans
alt.os.linux.slackware
(<podr5h$m7b$1...@solani.org>) :

> In case anyone has QMapShack installed on a Slackware current 64, how did
> you go about installing it? I guess it can be a very complex installation
> since it's a GIS program which utilises many libraries and toolkits.

Here is the sorted dependency "graph" for -current.

~# sbo_deps.py qmapshack
Checking for installed package qmapshack
qmapshack is not installed
Looking for qmapshack dependencies.
Checking for installed package gdal
gdal is not installed
Looking for gdal dependencies.
Checking for installed package geos
geos is not installed
Looking for geos dependencies.
Checking for installed package proj
Package proj found on system. Skipping...
Checking for installed package qt5-webkit
Package qt5-webkit found on system. Skipping...
Checking for installed package routino
routino is not installed
Looking for routino dependencies.
Checking for installed package quazip
quazip is not installed
Looking for quazip dependencies.
What next ?
[I] - Install qmapshack and all needed dependencies
[B] - Build qmapshack (no installation) and all needed dependencies
[L] - List qmapshack dependencies that will be installed
[A] - Abort
A

You just need to install these libraries in the right order (from bottom
to top of the list).

Do not mix different sources of precompiled packages unless you
want to mess your system up. Simply use sbopkg and it will do fine.

If you don't want to use sbopkg, a least, use only one repository.

--
Et l'on pousse à fond les moteurs
À s'en faire péter la turbine.
C'est tellement classe d'être loser
Surtout les matins où ça winne.
-- H.F. Thiéfaine, Errer humanum est

[Tuxedo]

Ars Ivci wrote:

[...]

>>
>> Meanwhile, I found qt5-5.11.2 at
>> http://www.slackware.com/~alien/slackbuilds/qt5/pkg/current/ and
>> installed it by installpkg:
>>
>
> ^^^
> This is a 32-bit package; it should have been .../qt5/pkg64/...
>
> [...]
>
>> qt5 (sbopkg did not work but installpkg with version from
>> http://www.slackware.com/~alien/slackbuilds/qt5/pkg/current/ did)
>
> ^^^
> Another 32-bit package.
>
> I do not know anything about qmaps, is it a 32-bit app or does it require
> anything 32-bit? Maybe someone who used it before can shed some light.
>
> If I were you, I'd clean everyhing, take a deep breath and start over with
> fresh eyes and always sticking to 64-bit binaries.
>

Thanks. I think however I need to set up multilib on this system, at least
if I'd like QMapShack to run.

Tuxedo

[Tuxedo]

Henrik Carlqvist wrote:

[...]

>> ... but the file exist on the system in /usr/lib/libproj.so.12
>
> No, those dynamic library files belwo /usr/lib are supposed to be 32 bit
> library files for 32 bit applications, useful for multilib installations.
> 64 bit applications search for their dynamic library files in /usr/lib64.

Thanks for the info. In this case, QMapShack uses 32 bit libraries although
it's not a 32 but application, which may explain why it was no problem for
me to get the program running on a previous 64 bit Slackware with multilib.

On https://bitbucket.org/maproom/qmapshack/wiki/Home

Unsupported Systems:
Due to limited resources a few operating system versions are not supported:
Linux 32bit versions
Windows 32bit versions
OS X < 10.8

Tuxedo

[Tuxedo]

Doug713705 wrote:

[...]

> You just need to install these libraries in the right order (from bottom
> to top of the list).
>
> Do not mix different sources of precompiled packages unless you
> want to mess your system up. Simply use sbopkg and it will do fine.
>
> If you don't want to use sbopkg, a least, use only one repository.

Sbopkg works great in my experience, but obviously it would then be best to
avoid slpkg.

Is sbo_deps.py your own procedure or an open script from somewhere? It looks
useful.

Tuxedo

[Tuxedo]

Ars Ivci wrote:

[...]

> If I were you, I'd clean everyhing, take a deep breath and start over with
> fresh eyes and always sticking to 64-bit binaries.

Before starting over again and taking a deep breath can you or anyone give
some advise on how to clean the system?

Over a couple of days I've installed a number of libraries using sbopkg,
installpkg and slpkg. As I can't remember all, are there logs what has been
installed manually or semi-automatically (in slpkg) as dependencies?

If it's best to stick with one package manager, e.g. sbopkg, would it
generally be Ok also to use installpkg or is installpkg considered a package
manager which could result in conflicts with sbopkg's standard procedures?

Tuxedo

[Ars Ivci]

I beg to differ here. Qmaps says they do *NOT* support 32-bit versions. I do not think a multilib setup is required (caution: I have never used qmaps). You are missing a few deps which by mistake you installed 32-bit versions of.

--
peace,
t.

[Giovanni]

On 09/26/2018 07:55 AM, Tuxedo wrote:

> If it's best to stick with one package manager, e.g. sbopkg, would it
> generally be Ok also to use installpkg or is installpkg considered a
> package manager which could result in conflicts with sbopkg's
> standard procedures?

The utilities from pkgtools package are the official tools and IMO are
the most reliable for installing and removing packages.

[Tuxedo]

Ars Ivci wrote:

[...]

> I beg to differ here. Qmaps says they do *NOT* support 32-bit versions. I
> do not think a multilib setup is required (caution: I have never used
> qmaps). You are missing a few deps which by mistake you installed 32-bit
> versions of.

After installing mapshack-1.11.1-x86_64-1_slonly.txz using installpkg,
executing qmapshack does not work. The shell exits with the message:

"qmapshack: error while loading shared libraries: libproj.so.12: cannot open
shared object file: No such file or directory"

The source make process of QMapShack 1.12.0 also returns a following warning
at line 369: https://pastebin.com/hUskhs0v

"/usr/bin/ld: warning: libproj.so.12, needed by /usr/lib64/gcc/x86_64-

slackware-linux/8.2.0/../../../../lib64/libgdal.so, not..."

And if libproj.so.12 is a 32 bit only application, maybe QMapShack requests
a multilib system after all?

Anyway, I don't think it can harm to have the multilib setup enabled on my
newly installed 64 bit system, if only to kill my curiousity.

Or has anyone here set up QMapShack on a 64-bit system without multilib?

Tuxedo

[Ars Ivci]

libproj.so.12 is a dynamic library. If you downloaded it from slackbuilds.org, running the slackbuild should have compiled Slackware package and placed it in /tmp. Upon which, you are required to install it with installpkg /tmp/something-with-proj-x84-64.txz (am guessing the name). Are you sure you installed it?

--
peace,
t.

[Tuxedo]

Ars Ivci wrote:

[...]

> libproj.so.12 is a dynamic library. If you downloaded it from
> slackbuilds.org, running the slackbuild should have compiled Slackware
> package and placed it in /tmp. Upon which, you are required to install it
> with installpkg /tmp/something-with-proj-x84-64.txz (am guessing the
> name). Are you sure you installed it?

Good question! I can't remember how I may have installed or upgraded it now
and indeed there's a proj-5.2.0-x86_64-1_SBo.tgz in /tmp

But as far as I remember, the particular libproj.so.12 file relates to
proj-4, which as far as I understand is supposed to be a 32-bit library but
which happens to be requested by the QMapShack 64-bit application.

which proj|xargs ls -l returns:
-rwxr-xr-x /usr/bin/proj root root 22048 Aug 2 /usr/bin/proj

It's a binary file and not very large. Could that be the Proj library?

Tuxedo

[Ars Ivci]

Don't know but you are now in Slackland, in the true sense of the meaning (no automated package managers): Installing it with installpkg would not hurt as you can remove it by removepkg. First check to see if you had installed proj, see if it is listed in /var/log/packages. This is the place where a list all installed packages handled by pkgtools (installpkg and removepkg) reside.

--
peace,
t.

[Doug713705]

Le 2018-09-26, Tuxedo nous expliquait dans
alt.os.linux.slackware
(<pof606$gae$3...@solani.org>) :

sbo_deps_py is my own wrapper python script around sbopkg that allow
dependency resolution for packages provided by slackbuilds.org only.

It's an open script available here:
https://github.com/doug-letough/sbo_deps.py

It works pretty well but it has some limitations on dependencies
resolution. For example trying to install ffmpeg, which is known to have
an huge dependency graph with many combinations, from sbo_deps.py will
fail. In this case you should handle the chainsaw yourself ;-)

However it will not help in official packages dependencies resolution.
I have an another script for that purpose that has only one use case:
- Checking that all installed packages have all their needed dependencoes
installed (check is based on ldd output on every installed executables
and libraries).

[Doug713705]

Le 2018-09-26, Tuxedo nous expliquait dans
alt.os.linux.slackware

(<pof78p$h0p$1...@solani.org>) :

sbopkg uses installpkg/upgradepkg/removepkg to install/upgrade/remove
packages so there is no conflict between theses tools.

More over, sbopkg does *not* install/uninstall official packages so it
will not mess your base system.

The problem with your way of using slpkg beside sbopkg and slackpkg is
that you are mixing the package sources and you've installed binary packages
that you know nothing of resulting in conflicting package versions, missing
libraries and probably an unstable system.

That is not the "Slack way" (if any) to do things.
Most of Slackware users will install non-official packages from sources
using sbopkg to facilitate some actions that, back in the days, was very
boring and time consuming.

Sbopkg is not a "real" package manager as in Debian or CentOS. It's more
something like an "advanced compilation and packaging helper".

You should choose a way to do what you want to do *and* stick to it once
for all.

--
On vit comme ça par habitude
Et surtout parce que c'est pratique
De pallier la solitude
En buvant à la même barrique
-- H.F. Thiéfaine, La dèche, le twist et le reste

[Tuxedo]

Doug713705 wrote:

[...]

> It's an open script available here:
> https://github.com/doug-letough/sbo_deps.py

Thanks, I will make use of this.

Tuxedo

[...]

[Henrik Carlqvist]

On Wed, 26 Sep 2018 07:55:35 +0200, Tuxedo wrote:
> Before starting over again and taking a deep breath can you or anyone
> give some advise on how to clean the system?

As you wish to install packages from 3rd party sources like SBO I would
suggest to reinstall latest stable Slackware (that is Slackware 14.2).
You can't expect third party package providers to keep up with Slackware
current which might change from day to day.

Then, once you have a new fresh stable system, be careful which packages
you install, avoid installing downloaded binary packages. As packages
might depend upon each other, best is to choose one source of packages
with consistent versions which hopefully will work together.
Slackbuilds.org is usually a good choice here.

slpkg might not be a bad choice if you stick to only one package source.
A command like:

slpkg -s sbo somepackage

Will download, compile and install somepackage with all its dependencies
from source.

regards Henrik

[Tuxedo]

I tried 'sbo_deps.py qmapshack' which returned:

Checking for installed package qmapshack
qmapshack is not installed
Looking for qmapshack dependencies.
Checking for installed package gdal

Package gdal found on system. Skipping...

Checking for installed package qt5-webkit
Package qt5-webkit found on system. Skipping...
Checking for installed package routino

Package routino found on system. Skipping...
Checking for installed package quazip
Package quazip found on system. Skipping...

What next ?
[I] - Install qmapshack and all needed dependencies
[B] - Build qmapshack (no installation) and all needed dependencies
[L] - List qmapshack dependencies that will be installed
[A] - Abort

I selected [I] and the install procedure went on for about 10 minutes until
some errors occurred. I can't capture all output as there is a limited
history in the shell window. Anyway, I did not see anything going wrong
before the end part as below:

[...]

[ 57%] Building CXX object
src/qmapshack/CMakeFiles/qmapshack.dir/helpers/CToolBarSetupDialog.cpp.o
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarSetupDialog.cpp: In
member function \u2018void CToolBarSetupDialog::configure() const\u2019:
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarSetupDialog.cpp:84:49:
error: invalid use of incomplete type \u2018class QAction\u2019
availableItems << new CDialogItem(action->icon(),action-
>iconText(),action->objectName());
^~
In file included from
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarSetupDialog.cpp:20:
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarConfig.h:27:7: note:
forward declaration of \u2018class QAction\u2019
class QAction;
^~~~~~~
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarSetupDialog.cpp:84:64:
error: invalid use of incomplete type \u2018class QAction\u2019
availableItems << new CDialogItem(action->icon(),action-
>iconText(),action->objectName());
^~
In file included from
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarSetupDialog.cpp:20:
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarConfig.h:27:7: note:
forward declaration of \u2018class QAction\u2019
class QAction;
^~~~~~~
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarSetupDialog.cpp:84:83:
error: invalid use of incomplete type \u2018class QAction\u2019
availableItems << new CDialogItem(action->icon(),action-
>iconText(),action->objectName());
^~
In file included from
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarSetupDialog.cpp:20:
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarConfig.h:27:7: note:
forward declaration of \u2018class QAction\u2019
class QAction;
^~~~~~~
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarSetupDialog.cpp:88:19:
error: invalid use of incomplete type \u2018class QAction\u2019
if (action->isSeparator())
^~
In file included from
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarSetupDialog.cpp:20:
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarConfig.h:27:7: note:
forward declaration of \u2018class QAction\u2019
class QAction;
^~~~~~~
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarSetupDialog.cpp:90:52:
error: invalid use of incomplete type \u2018class QAction\u2019
selectedItems << new CDialogItem(action-
>icon(),"---------------",action->objectName());
^~
In file included from
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarSetupDialog.cpp:20:
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarConfig.h:27:7: note:
forward declaration of \u2018class QAction\u2019
class QAction;
^~~~~~~
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarSetupDialog.cpp:90:85:
error: invalid use of incomplete type \u2018class QAction\u2019
selectedItems << new CDialogItem(action-
>icon(),"---------------",action->objectName());
^~
In file included from
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarSetupDialog.cpp:20:
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarConfig.h:27:7: note:
forward declaration of \u2018class QAction\u2019
class QAction;
^~~~~~~
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarSetupDialog.cpp:94:44:
error: invalid use of incomplete type \u2018class QAction\u2019
QString configuredName = action->objectName();
^~
In file included from
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarSetupDialog.cpp:20:
/tmp/SBo/qmapshack-1.11.1/src/qmapshack/helpers/CToolBarConfig.h:27:7: note:
forward declaration of \u2018class QAction\u2019
class QAction;
^~~~~~~
make[2]: *** [src/qmapshack/CMakeFiles/qmapshack.dir/build.make:3313:
src/qmapshack/CMakeFiles/qmapshack.dir/helpers/CToolBarSetupDialog.cpp.o]
Error 1
make[1]: *** [CMakeFiles/Makefile2:180:
src/qmapshack/CMakeFiles/qmapshack.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

qmapshack:
Would you like to continue processing the rest of the
queue or would you like to abort? If this failed
package is a dependency of another package in the queue
then it may not make sense to continue.

(Y)es to continue, (N)o to abort, (R)etry the build?:

I aborted.

Do these errors give some indication of their possible cause(s)?

Tuxedo

[Tuxedo]

Tuxedo wrote:

[...]

> Do these errors give some indication of their possible cause(s)?
>
> Tuxedo

And these were the errors when when running make on the downloaded 1.12
version of QMapShack: https://pastebin.com/Ji1hmjt5

Either something is broken with my setup or the version of QMapShack is not
compatible with Slackware current.

By the way, I enabled multilib on the system by:

SLACKVER=current
mkdir multilib
cd multilib
lftp -c "open http://bear.alienbase.nl/mirrors/people/alien/multilib/ ;
mirror -c -e ${SLACKVER}"
cd ${SLACKVER}

upgradepkg --reinstall --install-new *.t?z

upgradepkg --install-new slackware64-compat32/*-compat32/*.t?z

But it made no difference to my latest QMapShack install attempt I guess.

Tuxedo

[root]

slackpkg clean-system

Why did you decide to use current instead of 14.2?
If you know that you can run your desired programs
under 14.2 why not just start over with 14.2?

[Tuxedo]

root wrote:

[...]

> slackpkg clean-system
>
> Why did you decide to use current instead of 14.2?
> If you know that you can run your desired programs
> under 14.2 why not just start over with 14.2?

I went with current based on the suggestions here and because 14.2 is no
longer up to date.

With the exception of QMapShack, so far everything works great!

Wi-Fi as well as SIM connection works out of the box with the builtin
Networkmanager, which is something I remember having had trouble getting to
work on my previous but similar hardware with 14.2 for example.

QMapShack may be problematic on current for whatever reason, perhaps as my
installation isn't done right. So to clean the system and start over again
is worth a try.

After 'slackpkg clean-system' tip, I guess it's a good idea to run:

slackpkg update
slackpkg upgrade-all

In case there were any package installations which didn't complete in my
original installation of current as I can remember a few CPU overheating
warnings running across the screen, maybe such problems will be fixed.

In case anyone has made QMapShack run on Slackware current 64 here, please
advise.

Many thanks,
Tuxedo

[Tuxedo]

Tuxedo wrote:

[...]

> Wi-Fi as well as SIM connection works out of the box with the builtin
> Networkmanager, which is something I remember having had trouble getting
> to work on my previous but similar hardware with 14.2 for example.

Another example is suspension or hibernation which I remember having had
problems getting to work on a similar but older hardware in combination with
14.2.

Perhaps Slackware current is generally better for up-to-date hardware,
especially with SSD storage. The hardware I've installed current on came out
in 2018.

At the same time, there are other issues, such as creating a boot media,
which I've still not found a solution to, but that perhaps relates to LVM
and LUKS and SSD rather than the Slackware version.

I guess it's something that will work out of the box in a future version.

Tuxedo

[Rich]

Tuxedo <tux...@mailinator.com> wrote:

> Tuxedo wrote:
> Perhaps Slackware current is generally better for up-to-date
> hardware, especially with SSD storage. The hardware I've installed
> current on came out in 2018.

Since Slackware-current is what another distro (debian/redhat/etc.)
would call "testing" or "development", this stands to reason. The
collection of items in the "development" branch will always, by
definition, be at least equal and usually more up to date than the
immediately prior "release" branch.

> At the same time, there are other issues, such as creating a boot media,
> which I've still not found a solution to, but that perhaps relates to LVM
> and LUKS and SSD rather than the Slackware version.

Since you were building an encrypted LVM on top of an emmc drive (if
memory serves it was an emmc drive) this issue is likely wholly
unrelated to Slackware and more related to your particular hardware and
chosen options stack. Note, I'm not saying your wish for an encrypted
LVM on top of emmc is wrong, but I do think the choice introduced an
added complexity layer for building a separate boot media that you did
not find a solution for as of yet. And it is this added complexity
that is the barrier, not Slackware.

[Tuxedo]

Rich wrote:

[...]

> Since you were building an encrypted LVM on top of an emmc drive (if
> memory serves it was an emmc drive) this issue is likely wholly
> unrelated to Slackware and more related to your particular hardware and
> chosen options stack. Note, I'm not saying your wish for an encrypted
> LVM on top of emmc is wrong, but I do think the choice introduced an
> added complexity layer for building a separate boot media that you did
> not find a solution for as of yet. And it is this added complexity
> that is the barrier, not Slackware.

The idea was to encrypt not only a user directory but also the root with
system files and directories and swap.

So I followed the details in the section "Combining LUKS and LVM" in
Slackware's README_CRYPT.TXT, while considering the SSD which affects the
LUKS part: https://docs.slackware.com/howtos:hardware:ssd

The drive is not and eMMC type of SSD as far as I know. The particular model
is MZ-V7E2T0BW:
https://www.samsung.com/us/computing/memory-storage/solid-state-drives/ssd-970-evo-nvme-m2-2tb-mz-v7e2t0bw/#specs
(click "See All Specs")

Tuxedo

[Rich]

Sorry, I meant NVME (which is the drive type for that link). That is
the newer, direct attachment, drives that use a different interface.
Which likely explains why 14.2 was troublesome. The kernel shipped
with 14.2 likely is not new enough to have the necessary drivers for
accessing the NVME type drives.

But that just adds an additional complication on top of the
complication of creating a boot stick when the main system drive's root
is an LVM with LUKS encryption layered on top. It is a worthy goal,
but it is a complicated goal as well.

It is also possible (very likely in fact) that the code in Slackware's
installer is not capable of creating a working secondary boot disk when
the main system is LUKS on top of LVM all accessing a NVME disk. I
could very well see Patrick considering that as an 'expert' level task
that he did not need to code into the "would you like to create a boot
usb" part of the installer, instead assuming that the 'experts' who
wished to do that level of complicated install will also know how to
setup a boot stick and initrd image for the same.

[Tuxedo]

Rich wrote:

[...]

> Sorry, I meant NVME (which is the drive type for that link). That is
> the newer, direct attachment, drives that use a different interface.
> Which likely explains why 14.2 was troublesome. The kernel shipped
> with 14.2 likely is not new enough to have the necessary drivers for
> accessing the NVME type drives.
>
> But that just adds an additional complication on top of the
> complication of creating a boot stick when the main system drive's root
> is an LVM with LUKS encryption layered on top. It is a worthy goal,
> but it is a complicated goal as well.
>
> It is also possible (very likely in fact) that the code in Slackware's
> installer is not capable of creating a working secondary boot disk when
> the main system is LUKS on top of LVM all accessing a NVME disk. I
> could very well see Patrick considering that as an 'expert' level task
> that he did not need to code into the "would you like to create a boot
> usb" part of the installer, instead assuming that the 'experts' who
> wished to do that level of complicated install will also know how to
> setup a boot stick and initrd image for the same.

The version I've installed is not 14.2 but Slackware current (4.14.67 #SMP),
and so far, with the exception of creating a boot media needed in the
unlikely event of a boot failure and the installation of the QMapShack
application, the system runs perfectly well.

The system boots via the MBR into the unencrypted /boot partition and from
there on to the LUKS encrypted partition with the LVM setup for root, home
and swap.

Getting LILO to work with an SSD was not complicated, but I'm indeed lacking
the expertise to create a boot stick and initrd image from the current
installation to boot into the LUKS partition. Meanwhile, I'm not touching
the working LILO setup.

I guess the boot stick creating tool part of the installer was built at a
time when the use of SSDs were still not very commonplace.

Tuxedo

[Rich]

Tuxedo <tux...@mailinator.net> wrote:
>
> I guess the boot stick creating tool part of the installer was built at a
> time when the use of SSDs were still not very commonplace.

Well, it is not that you have an SSD, it is that you have an NVME SSD.

Regular SATA SSD's look identical to SATA hard disk (which,
effectively, also 'look' /mostly/ identical (from a driver perspective)
to old ATA parallel cable disks).

And it is not that you have an SSD that is likely the cause of the boot
stick creation failing.

It is much more likely that the boot stick creator simply does not
create boot sticks that work with anything more than the 99% case
(which is: install on unencrypted, plain SATA attached disk (i.e.,
/dev/sda1, etc)).

You fall into the remaining 1%, and it is likely that the basic built
in script just does not handle that remaining 1%, which leaves you out
on your own to figure it out.

I've never looked at the book stick creator portion of the installer
(nor have I actually ever answered "yes" to the "would you like to
create" prompt). So the above are guesses, but it is not unusual to
find that things like this are not programmed to handle *all* the
possible combinations that someone might want to instal upon.

[Eef Hartman]

Rich <ri...@example.invalid> wrote:
> Regular SATA SSD's look identical to SATA hard disk (which,
> effectively, also 'look' /mostly/ identical (from a driver perspective)
> to old ATA parallel cable disks).

S-ATA disk handling again has been derived from SCSI disks, which is
what sd (device name/driver) original meant: scsi disk (the original
ATA used hd - hard disk - as device).

Of course SCSI then went from parallel to serial cabling too (SAS,
Serial Access SCSI), but the generic handling stayed the same.
They even incorporated the old "hd" handling into the "sd" driver so
that then all disks became sd ones.