slackpkg clean-all considerations

[Tuxedo]

Hello,

In short, my recent Slackware current installation, after setting up LVM,
encryption etc., I had a package selection included the following:

[*] Base Linux System
[*] Various applications that do not need X
[*] Program Development, (c, C++, Lisp, Perl, etc.)
[*] GNU Emacs
[*] FAQ lists, HOWTO documentation
[*] Linux kernel source
[*] KDE QT and the K Desktop Environment for X
[*] KDEI International Language Support for KDE
[*] System Libraries (some needed by both KDE and GNOME)
[*] Networking (TCP/IP, UUCP, Mail, News)
[*] TeX typesetting softare
[*] TCL Tcl/Tk scropt languages
[*] X Windows System
[*] X Appications
[*] XFCE The Xfce Desktop Envirobment for X
[*] Games

I also added a selection of various startup services:

rc.bind
rc.cups
rc.dnsmasq
rc.fuse
rc.http
rc.ip_forward
rc.ntpd
rc.inetd
rc.ip_forward
rc.messagebus
rc.ntpd
rc.rpc
rc.postfix
rc.rpc NFS daemons
rc.snmpd
rc.syslog
rc.sshd

... thereafter did the custom kernel with the mkinitrd_command_generator.sh
and manual LILO configuration. The image used when loading Linux is:
image = /boot/vmlinuz-generic-4.14.67

As far as I understand, 'slackpkg clean-all' will not change this setup?

It's suggested to uncomment kernel images in /etc/slackpkg/blacklist when
upgrading packages. Is this also relevant when doing the 'clean-all'?

#kernel-generic
#kernel-generic-smp
#kernel-huge
#kernel-huge-smp
#kernel-modules
#kernel-modules-smp
#kernel-source

After initial installation, I had added some packages which were simple to
install via sbo but there's no need to reinstall, so they can be temporarily
blacklisted:

sbopkg-0.38.1-noarch-1_wsr.tgz
perl-CGI-4.40-x86_64-1_SBo
perl-Image-Size-3.300-x86_64-1_SBo
perl-Sub-Uplevel-0.25-x86_64-1_SBo
perl-Test-Deep-1.127-x86_64-1_SBo
perl-Test-NoWarnings-1.04-x86_64-1_SBo
perl-html-parser-3.71-x86_64-1_SBo
perl-html-tagset-3.20-x86_64-1_SBo
perl-test-warn-0.36-x86_64-1_SBo
imagemagick-6.9.10_3-x86_64-1

From this point I've been trying but failing to get QMapShack working and in
the same process installing countless libraries by a mix of sbopkg, slpkg
and installpkg, so whatever conflicts those actions may have caused, their
resulting package installations can best be removed.

I uncomment some nearby mirror in /etc/slackpkg/mirrors

#----------------------------------------------------------------
# Slackware64-current
#----------------------------------------------------------------

# GERMANY (DE)
http://ftp.gwdg.de/pub/linux/slackware/slackware64-current/

I don't have an alternative booting method except the initial manual LILO
configuration, so I hope clean-all isn't going to change the original setup
in some default way that could get me locked out of the system. If so, how
do I prevent this from happening?

Are there other considerations that should be taken into account
before running 'slackpkg clean-all'?

Many thanks for any suggestions.

Tuxedo

[Doug713705]

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

Post by Tuxedo
I don't have an alternative booting method except the initial manual LILO
configuration, so I hope clean-all isn't going to change the original setup
in some default way that could get me locked out of the system. If so, how
do I prevent this from happening?

AFAIK slackpkg clean-system (there is no clean-all option) will not
delete or replace any configuration file so all the services usually
started at boot will still be started after clean-system.

So you can't be locked out with clean-system.

Post by Tuxedo
Are there other considerations that should be taken into account
before running 'slackpkg clean-all'?

Backup the compiled SBo packages if you plan to reinstall some of them.
It will save you some compilation time.

[Tuxedo]

Doug713705 wrote:

[...]

Post by Doug713705
AFAIK slackpkg clean-system (there is no clean-all option) will not
delete or replace any configuration file so all the services usually
started at boot will still be started after clean-system.
So you can't be locked out with clean-system.

I don't know where 'clean-all' came from. I even looked at the manual. I
meant 'clean-system'.

[...]

Post by Doug713705
Backup the compiled SBo packages if you plan to reinstall some of them.
It will save you some compilation time.

I only installed very few packages so far.

Thanks for the feedback. I will start with the cleaning :-)

Tuxedo

[Tuxedo]

Tuxedo wrote:

[...]

Post by Tuxedo
Thanks for the feedback. I will start with the cleaning :-)

[...]

In starting the cleaning, I do:

~# slackpkg clean-system

.. which returns:

The package list is missing.
Before you install|upgrade|reinstall anything you need to run:

# slackpkg update

So I run:

~# slackpkg update

But that returns:


You have selected a mirror for Slackware -current in /etc/slackpkg/mirrors,
but Slackware version 14.2+ appears to be installed.

Slackware -current is the development (i.e. unstable) tree.

Is this really what you want?

To confirm your choice, press Y, else press N. Then, press Enter:


I'm getting confused. I'm sure I installed current from an iso a few weeks
ago at http://bear.alienbase.nl/mirrors/slackware/slackware64-current-iso/

So for now I press 'N'.

Did I perhaps install 14.2! I doubt it. The system doesn't look anywhere
close to the 14.2 system I installed last year.

I run:

~# uname -srvo

which returns:

~# Linux 4.14.67 #2 SMP Fri Aug 24 16:03:02 CDT 2018 GNU/Linux

Does slackpkg's message above incorrectly identify the current installation
as 14.2? If so, should I simply ignore this message hit 'Y' to proceed?

Tuxedo

[Ars Ivci]

On Thu, 27 Sep 2018 22:42:42 +0200

Post by Tuxedo
Did I perhaps install 14.2! I doubt it. The system doesn't look anywhere
close to the 14.2 system I installed last year.
~# uname -srvo
~# Linux 4.14.67 #2 SMP Fri Aug 24 16:03:02 CDT 2018 GNU/Linux

Kernel shows that you installed current, indeed. 14.2 is using 4.4.153.

Post by Tuxedo
Does slackpkg's message above incorrectly identify the current installation
as 14.2? If so, should I simply ignore this message hit 'Y' to proceed?
Tuxedo

Never used these, so can't help.

[Tuxedo]

Ars Ivci wrote:

[...]

Post by Ars Ivci
Kernel shows that you installed current, indeed. 14.2 is using 4.4.153.

[...]

Thanks for clearing my confusion. It had made me think I might have used the
wrong USB stick for the installation.

I guess hitting 'Y' should be Ok here.

Tuxedo

[root]

Post by Tuxedo
Did I perhaps install 14.2! I doubt it. The system doesn't look anywhere
close to the 14.2 system I installed last year.

The file /etc/slackware-version tells which version is installed.
I'm not sure, but I think Slackware current is still
14.2. In the course of this thread I installed current
and I think /etc/slackware-version still showed 14.2


I want to repeat that your concern about losing the MBR should
cause you to look again into grub since it has a built in
recovery for a lost MBR.

Post by Tuxedo
Tuxedo

[Tuxedo]

root wrote:

[...]

Post by root
The file /etc/slackware-version tells which version is installed.
I'm not sure, but I think Slackware current is still
14.2. In the course of this thread I installed current
and I think /etc/slackware-version still showed 14.2

On my current installation /etc/slackware-version reads: Slackware 14.2+

Post by root
I want to repeat that your concern about losing the MBR should
cause you to look again into grub since it has a built in
recovery for a lost MBR.

I've used GRUB before and I'm aware of that it has more options, most of
which I probably won't need for my simple dual-boot laptop machine.

So far I've never had a problem with LILO, so I think I'll stick to good old
LILO for now.

I guess either LILO or Grub could be used on a boot stick, or maybe it's
even possible to somehow boot into the LUKS encrypted Slackware partition
via a Slackware Live media.

Using Unetbootin, I recently made a Slackware Live media from slackware64-
live-current.iso which has a not much different version kernel from my
current HD installation.

On the Slackware Live media, uname -a returns:
Linux darkstar.example.net 4.14.68 #2 SMP Wed Sep 5 22:150:21 CDT 2018
x86_64 Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz GenuineIntel GNU/Linux

My /boot partition contains various kernels. The one LILO was configured to
boot with is vmlinuz-generic-4.14.67.

Tuxedo

[Michael Black]

Post by root

Post by Tuxedo
Did I perhaps install 14.2! I doubt it. The system doesn't look anywhere
close to the 14.2 system I installed last year.

The file /etc/slackware-version tells which version is installed.
I'm not sure, but I think Slackware current is still
14.2. In the course of this thread I installed current
and I think /etc/slackware-version still showed 14.2

Back on April 19th, the changelog had a bit about this:
a/aaa_base-14.2-i586-4.txz: Rebuilt.
In /etc/os-release, change PRETTY_NAME to:
PRETTY_NAME="Slackware 14.2 $ARCH (post 14.2 -current)"

So that's not the same as "slackware-version", but it sounds like now
it will indicate whether it's release or if you've been following along
with current. But maybe not.

Michael

Post by root
I want to repeat that your concern about losing the MBR should
cause you to look again into grub since it has a built in
recovery for a lost MBR.

Post by Tuxedo
Tuxedo

[Tuxedo]

Michael Black wrote:

[...]

Post by Michael Black
a/aaa_base-14.2-i586-4.txz: Rebuilt.
PRETTY_NAME="Slackware 14.2 $ARCH (post 14.2 -current)"
So that's not the same as "slackware-version", but it sounds like now
it will indicate whether it's release or if you've been following along
with current. But maybe not.

[...]

In /etc/os-release on my installation the following details are shown:

NAME=Slackware
VERSION="14.2"
ID=slackware
VERSION_ID=14.2
PRETTY_NAME="Slackware 14.2 x86_64 (post 14.2 -current)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:slackware:slackware_linux:14.2"
HOME_URL="http://slackware.com/"
SUPPORT_URL="http://www.linuxquestions.org/questions/slackware-14/"
BUG_REPORT_URL="http://www.linuxquestions.org/questions/slackware-14/"
VERSION_CODENAME=current

Tuxedo

[Tuxedo]

Tuxedo wrote:

[...]

To clean-system, I ran 'slackpkg update' and thereafter:

slackpkg clean-system

Next I'm prompted to choose packages to remove, which are a bit over 200
packages. Why there are so many is because most are ending with compat32 as
I installed multilib.

As far as I understand, the selection includes all I've installed after the
base installation, less those packages I've added in the blacklist. So I
guess it shoould be OK simply to select all without knowing exactly what
each package does, while remaining sure to have a working system after.

Tuxedo

[Tuxedo]

SBo is of course not part of the base installation. As such, when running
Slackware current, should SBo perhaps be specially configured for use with
the current branch?

On my current set up, in /etc/sbopkg/repos.d/, the following files exist:
40-sbo.repo
50-local.repo
60-SBo-current.repo
90-SBo-master.repo

40-sbo.repo contains:
# DO NOT EDIT THIS FILE. CHANGES WILL BE OVERWRITTEN. See the README.
# Repo Branch Description Tag Tool Link CheckGPG
SBo 14.2 "SBo repository for Slackware 14.2" _SBo rsync
slackbuilds.org::slackbuilds/14.2 GPG
SBo 14.1 "SBo repository for Slackware 14.1" _SBo rsync
slackbuilds.org::slackbuilds/14.1 GPG
SBo 14.0 "SBo repository for Slackware 14.0" _SBo rsync
slackbuilds.org::slackbuilds/14.0 GPG
SBo 13.37 "SBo repository for Slackware 13.37" _SBo rsync
slackbuilds.org::slackbuilds/13.37 GPG
SBo 13.1 "SBo repository for Slackware 13.1" _SBo rsync
slackbuilds.org::slackbuilds/13.1 GPG
SBo 13.0 "SBo repository for Slackware 13.0" _SBo rsync
slackbuilds.org::slackbuilds/13.0 GPG
SBo 12.2 "SBo repository for Slackware 12.2" _SBo rsync
slackbuilds.org::slackbuilds/12.2 GPG
SBo 12.1 "SBo repository for Slackware 12.1" _SBo rsync
slackbuilds.org::slackbuilds/12.1 GPG
SBo 12.0 "SBo repository for Slackware 12.0" _SBo rsync
slackbuilds.org::slackbuilds/12.0 GPG
SBo 11.0 "SBo repository for Slackware 11.0" _SBo rsync
slackbuilds.org::slackbuilds/11.0 GPG

50-local.repo contains:
# DO NOT EDIT THIS FILE. CHANGES WILL BE OVERWRITTEN. See the README.
# Repo Branch Description Tag Tool Link CheckGPG
local local "default local repository" _SBo "" "" ""

60-SBo-current.repo contains:
# DO NOT EDIT THIS FILE. CHANGES WILL BE OVERWRITTEN. See the README.
# Repo Branch Description Tag Tool Link CheckGPG
SBo-git current "UNSUPPORTED SBo git repository for -current" ponce git
git://github.com/Ponce/***@current ""

90-SBo-master.repo contains:
SBo master "SBo master git branch" _SBo git
git://slackbuilds.org/***@master ""

Does this appear to be in order?

Tuxedo

[root]

Post by Tuxedo
Does this appear to be in order?

These threads have gone on so long I cannot keep up with the
state of your system. I forget which type of SSD you have
and I'm not sure why you must have an encrypted system.

Since you have not reached anything that seem stable
I would recommend pulling out the SSD and sticking
in a spinning drive with two partitions. The first
partition would be a stable operating plain vanilla Slackware.

The second partition would be for experimenting. Since it
only takes a few minutes to install a new Slack system
you can experiment all you want with the through-away
second partition.

As far as multilib goes I found it broke almost every
Slackbuilds script. I would avoid multilib unless there
is some application that you must have that is only
available for 32 bit systems. My wife runs multilib solely
to use Picasa.

Over the years I have saved the various packages I built
from Slackbuilds so it is easy to restore those for me.

In these various threads others have pointed out problems
with slpkg and binary repostitories. There are shortcomings
but, for me, the ease of use outways the downside.

Post by Tuxedo
Tuxedo

[Tuxedo]

root wrote:

[...]

Post by root
These threads have gone on so long I cannot keep up with the
state of your system. I forget which type of SSD you have
and I'm not sure why you must have an encrypted system.

Encryption is a necessity on any system that's carried around and which
could get lost, stolen etc.

Post by root
Since you have not reached anything that seem stable
I would recommend pulling out the SSD and sticking
in a spinning drive with two partitions. The first
partition would be a stable operating plain vanilla Slackware.

The particular Thinkpad model does not have room for an old spinning drive.
Besides, SSDs is the current technology and much faster.

Post by root
The second partition would be for experimenting. Since it
only takes a few minutes to install a new Slack system
you can experiment all you want with the through-away
second partition.
As far as multilib goes I found it broke almost every
Slackbuilds script. I would avoid multilib unless there
is some application that you must have that is only
available for 32 bit systems. My wife runs multilib solely
to use Picasa.

Thanks for the Slackbuild script warning with multilib. I didn't know there
were potential drawbacks. So maybe I'll remove multilib. It appears that
most applications are 64-bit nowadays anyway. I only installed multilib as
QMapShack appeared to request some 32-bit library, although it's a 64-bit
application.

I previously got QMapShack running on a 64 bit Slackware 14.2 stable which
happens to have multilib installed. Maybe on the current system, I just
still haven't got the dependencies set up correctly.

Post by root
Over the years I have saved the various packages I built
from Slackbuilds so it is easy to restore those for me.
In these various threads others have pointed out problems
with slpkg and binary repostitories. There are shortcomings
but, for me, the ease of use outways the downside.

I removed slpkg and plan to stick to SBo and installpkg as it's worked well
in the past, but who knows about the 'current' environment.

The main problem I've had so far is getting QMapShack to run, which is why
I'm curious in case anyone has made this application run in a Slackware
current 64-bit only environment. It's a very useful application to process
Garmin generated pathways etc., so in case anyone wants to test it in a
similar Slackwaree set up, please share your install procedures here.

The complicated LVM and LUKS configuration was a fun learning experience :-)

Tuxedo

[Rich]

Post by Tuxedo
The main problem I've had so far is getting QMapShack to run,

Someone else posted in an earlier reply some days ago that you had been
installing pre-compiled binary packages willy-nilly in your attempts to
get QMapShack to run.

If this statement was true, then some portion (possibly almost all) of
your difficulties may have come from installing these pre-compiled
binary packages. If any one of them happened to /require/ a specific
point level of another library where Slack-current provides a different
point level, then you would have had a dependency incompatibility right
there.

I.e., a dependent library X of QMapShack itself requires specifically
at least 5.4.3 of library Y.

But slackware provides the 5.4.1 version of library Y.

Ultimately QMapShack, from pre-compiled blobs, and assuming an above
situation, would never run because a grand-kid dependency is not
properly satisfied.


One of the dangers with pre-compiled binaries is that if they are
compiled on a 'bleeding edge' distro (much more 'bleeding edge' than
even Slack-current, and several other Linux distros tend to fit this
description) then they will often be linked to 'bleeding edge' versions
of their dependencies, and of the next level dependencies, etc. The
result is those binaries will not run on Slack until Slack eventually
catches up to those bleeding edge versions (generally when those
bleeding edges become 'current stable' versions). Of course, by that
point, the 'bleeding edge' distro will be several more versions ahead
again in 'bleeding edge' releases.

[Tuxedo]

Rich wrote:

[...]

Post by Rich
Someone else posted in an earlier reply some days ago that you had been
installing pre-compiled binary packages willy-nilly in your attempts to
get QMapShack to run.
If this statement was true, then some portion (possibly almost all) of
your difficulties may have come from installing these pre-compiled
binary packages. If any one of them happened to /require/ a specific
point level of another library where Slack-current provides a different
point level, then you would have had a dependency incompatibility right
there.
I.e., a dependent library X of QMapShack itself requires specifically
at least 5.4.3 of library Y.
But slackware provides the 5.4.1 version of library Y.
Ultimately QMapShack, from pre-compiled blobs, and assuming an above
situation, would never run because a grand-kid dependency is not
properly satisfied.
One of the dangers with pre-compiled binaries is that if they are
compiled on a 'bleeding edge' distro (much more 'bleeding edge' than
even Slack-current, and several other Linux distros tend to fit this
description) then they will often be linked to 'bleeding edge' versions
of their dependencies, and of the next level dependencies, etc. The
result is those binaries will not run on Slack until Slack eventually
catches up to those bleeding edge versions (generally when those
bleeding edges become 'current stable' versions). Of course, by that
point, the 'bleeding edge' distro will be several more versions ahead
again in 'bleeding edge' releases.

Thanks for explaining. It makes sense. Maybe the application will simply not
work in the current mix of libraries and dependencies and so I just have to
live with booting in and out of Windows whenever I'm needing QMapShack,
perhaps for as long as today's current has not yet become Slackware 15.0.

Tuxedo

[Rich]

Post by Tuxedo
[...]

Post by Rich
Someone else posted in an earlier reply some days ago that you had been
installing pre-compiled binary packages willy-nilly in your attempts to
get QMapShack to run.
If this statement was true, then some portion (possibly almost all) of
your difficulties may have come from installing these pre-compiled
binary packages. If any one of them happened to /require/ a specific
point level of another library where Slack-current provides a different
point level, then you would have had a dependency incompatibility right
there.
I.e., a dependent library X of QMapShack itself requires specifically
at least 5.4.3 of library Y.
But slackware provides the 5.4.1 version of library Y.
Ultimately QMapShack, from pre-compiled blobs, and assuming an above
situation, would never run because a grand-kid dependency is not
properly satisfied.
One of the dangers with pre-compiled binaries is that if they are
compiled on a 'bleeding edge' distro (much more 'bleeding edge' than
even Slack-current, and several other Linux distros tend to fit this
description) then they will often be linked to 'bleeding edge' versions
of their dependencies, and of the next level dependencies, etc. The
result is those binaries will not run on Slack until Slack eventually
catches up to those bleeding edge versions (generally when those
bleeding edges become 'current stable' versions). Of course, by that
point, the 'bleeding edge' distro will be several more versions ahead
again in 'bleeding edge' releases.

Thanks for explaining. It makes sense. Maybe the application will simply not
work in the current mix of libraries and dependencies and so I just have to
live with booting in and out of Windows whenever I'm needing QMapShack,
perhaps for as long as today's current has not yet become Slackware 15.0.

Or, you go the Slackware route and actually compile from source bundles
the various pieces you need including QMapShack itself.

Either you'll get all the parts compiled and have a working QMapShack,
or you'll eventually locate exactly the location where dependent
library X needs version Q of library Y, where Slackware only has
something less than Q.

Then you can decide if you want to compile a Q version of Y to replace
Slackwares version (or compile a custom version to live in a custom lib
dir used just for QMapShack).

[Tuxedo]

Rich wrote:

[...]

Post by Rich
Or, you go the Slackware route and actually compile from source bundles
the various pieces you need including QMapShack itself.

If I only knew how to I would. Instead, I think I have no choice but to wait
for someone else to do the hard work :-)

Post by Rich
Either you'll get all the parts compiled and have a working QMapShack,
or you'll eventually locate exactly the location where dependent
library X needs version Q of library Y, where Slackware only has
something less than Q.
Then you can decide if you want to compile a Q version of Y to replace
Slackwares version (or compile a custom version to live in a custom lib
dir used just for QMapShack).

[Rich]

Post by Tuxedo
[...]

Post by Rich
Or, you go the Slackware route and actually compile from source bundles
the various pieces you need including QMapShack itself.

If I only knew how to I would. Instead, I think I have no choice but to wait
for someone else to do the hard work :-)

For the vast majority it entails:

1) unpack source bundle - cd to top level dir - read README or INSTALL
files to see if there is anything 'interesting'

2) perform these commands:

# ./configure
# make
# make install DESTDIR=/tmp/temp-name
# cd /tmp/temp-name
# makepkg ../packagename-version-arch-slackpackageversioncode

Where "packagename" is the name you want to use to install
"version" is typically something like 5.1.3
"arch" is either "i386" or "x86_64" depending upon your systems cpu
architecture
"slackpackageversioncode" is usally a numeral, but for my own custom
local ones, I usually use "1_mine" so they stick out in
/var/log/packages listings.

Followed by
# installpkg ../packagename-version-arch-slackpackageversioncode

Note, for real installs, you are better off running the above as the
root user (you can actually do it all as non-root until the "makepkg"
and there you do need to change the ownership of everthing to root
before makeing and installing the package (if you don't, installing a
slack package created by a non-root user will change the ownership of
all the directories touched by the package to that non-root user, which
generally creates odd errors quickly, but is recoverable by just
changing the ownership back to root)).

If you are unsure about a package, you can do all the above as a
non-root up until just before the "makepkg" call, then inspect what was
created to make sure everything is where you want it. If not, go back
and adjust the ./configure call (sometimes it needs to be given a
parameter to change from installing into /usr/local to install into
/usr and to put man pages where Slack stores them).


Now, for items on SBo, it entails downloading the SBo package and the
source bundle that goes along. Verifying the md5sum if you want to
make sure you got the same source bundle as the maintainer used to
create the slackbuild script, and running the slackbuild script as
root. It will do all of the above steps and when it finishes (if there
are not errors) you'll have a slack package in /tmp/ ready to install.
So if something you want is on Slackbuilds, then they are much easier
to use as they take care of everything. Also many SBo's will also
build 'bleeding edge' versions with few problems as well, provided you
call them in a slightly special way:

VERSION=5.4.3 ./newpackage.SlackBuild

You find the version code from the source bundle file.

[Tuxedo]

Rich wrote:

[...]

Post by Rich
1) unpack source bundle - cd to top level dir - read README or INSTALL
files to see if there is anything 'interesting'
# ./configure
# make
# make install DESTDIR=/tmp/temp-name
# cd /tmp/temp-name
# makepkg ../packagename-version-arch-slackpackageversioncode
Where "packagename" is the name you want to use to install
"version" is typically something like 5.1.3
"arch" is either "i386" or "x86_64" depending upon your systems cpu
architecture
"slackpackageversioncode" is usally a numeral, but for my own custom
local ones, I usually use "1_mine" so they stick out in
/var/log/packages listings.
Followed by
# installpkg ../packagename-version-arch-slackpackageversioncode
Note, for real installs, you are better off running the above as the
root user (you can actually do it all as non-root until the "makepkg"
and there you do need to change the ownership of everthing to root
before makeing and installing the package (if you don't, installing a
slack package created by a non-root user will change the ownership of
all the directories touched by the package to that non-root user, which
generally creates odd errors quickly, but is recoverable by just
changing the ownership back to root)).
If you are unsure about a package, you can do all the above as a
non-root up until just before the "makepkg" call, then inspect what was
created to make sure everything is where you want it. If not, go back
and adjust the ./configure call (sometimes it needs to be given a
parameter to change from installing into /usr/local to install into
/usr and to put man pages where Slack stores them).
Now, for items on SBo, it entails downloading the SBo package and the
source bundle that goes along. Verifying the md5sum if you want to
make sure you got the same source bundle as the maintainer used to
create the slackbuild script, and running the slackbuild script as
root. It will do all of the above steps and when it finishes (if there
are not errors) you'll have a slack package in /tmp/ ready to install.
So if something you want is on Slackbuilds, then they are much easier
to use as they take care of everything. Also many SBo's will also
build 'bleeding edge' versions with few problems as well, provided you
VERSION=5.4.3 ./newpackage.SlackBuild
You find the version code from the source bundle file.

The QMapShack build procedure may be somewhat different, as detailed on
https://bitbucket.org/maproom/qmapshack/overview

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

I will consult your instructions for other applications. As for QMapShack, I
think I'll wait for a more stable version of Slackware current and/or
QMapShack.

Many thanks,
Tuxedo

[Eef Hartman]

SBo perhaps be specially configured for use with the current branch?

Essentially most SlackBuilds are for the _released_ versions of
Slackware only, so 14.?
Quite a few will still work in -current, but there is NO guarantee as
they haven't been tested IN that environment (excepting the
SBo-current ones, but even they may be for an _older_ version of
-current).
That's why i.e. qt should not be installed from SBo (too old) but from
alien's KTown (which _is_ available for -current).

I just read (on LinuxQuestions.org) that the package skype doesn't run
on -current anymore as the C-library is incompatible with it.

[Ars Ivci]

Post by Eef Hartman

SBo perhaps be specially configured for use with the current branch?

I just read (on LinuxQuestions.org) that the package skype doesn't run
on -current anymore as the C-library is incompatible with it.

It requires systemd-logind.

[Tuxedo]

Ars Ivci wrote:

[...]

Post by Ars Ivci

Post by Eef Hartman
I just read (on LinuxQuestions.org) that the package skype doesn't run
on -current anymore as the C-library is incompatible with it.

It requires systemd-logind.

I would never expect Skype to work in anything except Windows and who knows
whenever Microsoft suddenly blocks a current version for whatever reason, I
found that a slightly earlier version than the one found in SBo still works:
https://slackware.pkgs.org/14.2/slackel-x86_64/skypeforlinux-8.19.76.3-x86_64-1dj.txz.html

Tuxedo

[Ars Ivci]

Post by Tuxedo
[...]

Post by Ars Ivci

Post by Eef Hartman
I just read (on LinuxQuestions.org) that the package skype doesn't run
on -current anymore as the C-library is incompatible with it.

It requires systemd-logind.

I would never expect Skype to work in anything except Windows and who knows
whenever Microsoft suddenly blocks a current version for whatever reason, I
https://slackware.pkgs.org/14.2/slackel-x86_64/skypeforlinux-8.19.76.3-x86_64-1dj.txz.html
Tuxedo

Skype is working. Its old version is not working with current's C-lib
while its new version will require systemd which Slackware does (will)
not have.

[Tuxedo]

Ars Ivci wrote:

[...]

Post by Ars Ivci
Skype is working. Its old version is not working with current's C-lib
while its new version will require systemd which Slackware does (will)
not have.

I barely know anyone who's still connected on Skype.

Tuxedo

[Tuxedo]

Tuxedo wrote:

[...]

Post by Tuxedo
As far as I understand, the selection includes all I've installed after
the base installation, less those packages I've added in the blacklist. So
I guess it shoould be OK simply to select all without knowing exactly what
each package does, while remaining sure to have a working system after.

It was easy enough identify the packages (qt5, proj, graphviz and more) that
may have been incorrectly installed by a mix of package managers to make the
system clean enough and start over with QMapShack and it its dependencies.

I guess there's no need to remove the many compat32 packages as there were
no errors with the multilib setup procedure.

Tuxedo