mailutils launching issue [SOLVED]

[Member dukester]

I compiled the lot from the tarball. Zero issues showed up.
sudo make install afterwards. Zero issues showed up.

$> movemail

movemail: error while loading shared libraries: libmu_mbox.so.8:
cannot open shared object file: No such file or directory

ls -l /usr/local/lib/libmu_mbox.so.*
/usr/local/lib/libmu_mbox.so.8 -> /usr/local/lib/libmu_mbox.so.8.0.0

/usr/local/bin and /usr/local/lib are in $PATH

uname -a
Linux antixbox 4.9.235-antix.1-amd64-smp #1 SMP PREEMPT
Mon Sep 14 19:26:52 EEST 2020 x86_64 GNU/Linux

Need a solution please. Any ideas why this is happening? 32 vs 64 bit issue? TIA …

• This topic was modified 1 year, 7 months ago by dukester.

--
dukester

[Anonymous]

Helpful

Up

0

::

I compiled the lot from the tarball.

Unsure why you chose to do so, considering that Debian -compatible packages are already available https://sources.debian.org/src/mailutils/

Any ideas why this is happening?

The “why” may become self-evident if you
git clone https://salsa.debian.org/debian/mailutils
and diff (via a GUI e.g. kdiff3-qt, or meld) what’s absent//different in your “from tarball” source tree vs the “for debian” source tree

[Member dukester]

Helpful

Up

0

::

I compile from the tarball because the version I get using `synaptic’ reports a dependency issue and chokes!
So what’s your solution now that you know this?

--
dukester

[Member dukester]

Helpful

Up

0

::

I just DLed the tarball from the link you provided and re-compiled.

NO JOY! Very same issue exists after the re-compile!

Now what? :/

--
dukester

[Anonymous]

Helpful

Up

0

::

DLed the tarball from the link you provided and re-compiled.

Whoops, I linked to that because it seemed like you WANTED to self-compile
(and that you would appropriately choose which git branch to clone, and… )

– – –

Which version of antiX? Is the system configured to use debian stable, or testing, (or sid) packages repositories?

You haven’t mentioned where you obtained the tarball. Hopefully it provides a “make uninstall” target (a cleanup is probably a prequisite to now attempting installation of the debian packaged version)

skip synaptic and, from commandline: sudo apt install mailutils
Paste into a followup post (within CODE tags) the output of the “dependency issue and chokes” message

[Member dukester]

Helpful

Up

0

::

Hey ..

Look at `uname’ in my original post.
Got the first tarball uninstalled first of all.
Then I installed again from the link you provided.

I now get the very same error message that I state in my original post.

sudo apt install mailutils
[sudo] password for dnormandin:
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
mailutils : Depends: mailutils-common (= 1:3.10-3) but 1:3.11.1-5 is to be installed
E: Unable to correct problems, you have held broken packages.

--
dukester

[Member dukester]

Helpful

Up

0

::

inxi -r
Repos: Active apt repos in: /etc/apt/sources.list
1: deb http://deb.debian.org/debian/ buster non-free contrib main
Active apt repos in: /etc/apt/sources.list.d/antix.list
1: deb http://la.mxrepo.com/antix/bullseye/ bullseye main nosystemd nonfree
Active apt repos in: /etc/apt/sources.list.d/bullseye-backports.list
1: deb http://deb.debian.org/debian bullseye-backports main contrib non-free
Active apt repos in: /etc/apt/sources.list.d/buster-backports.list
1: deb http://deb.debian.org/debian/ buster-backports non-free contrib main
Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list
1: deb http://ftp.us.debian.org/debian/ bullseye-updates main contrib non-free
Active apt repos in: /etc/apt/sources.list.d/debian.list
1: deb http://ftp.gr.debian.org/debian/ bullseye main contrib non-free
2: deb http://security.debian.org/ bullseye-security main contrib non-free
No active apt repos in: /etc/apt/sources.list.d/onion.list
No active apt repos in: /etc/apt/sources.list.d/various.list

--
dukester

[Anonymous]

Helpful

Up

0

::

>> Which version of antiX?

> Look at `uname’ in my original post.

Was asking “version + repos” as in “antiX 19.4, using debian stable (bullseye) repos” or…
so that I and others could gauge whether your system is consulting the necessary//correct repositories.

Having both bullseye-backports and buster-backports enabled at the same time certainly smells wrong, for starters…

apt policy mailutils-common
^— for the problem immediately at hand, you might identify the repo offering pkg version “1:3.11.1-5” and disable it, then perform apt update + retry the mailutils installation

[Member dukester]

Helpful

Up

0

::

Thanks for all your input skidoo! Here’s what you were asking about:

inxi –system
System:
Host: antixbox Kernel: 4.9.235-antix.1-amd64-smp x86_64 bits: 64
Desktop: Fluxbox 1.3.7 Distro: antiX-19.3_x64-full Manolis Glezos 15 October 2020

Coming from a Slackware/FreeBSD background, the Debian repo system is a bit confusing to me. So I need a quick-n-dirty education on the subject, please, in order to minimize any future hassles. 🙂

What Debian repo should I be tracking? Why would compiling a latest version of a program – from git or wherever – break on a Debian-based distro if that tarball etc is dealing with all the dependencies as well? What if I want a more bleeding-edge version of some particular software? How should I do it and not break everything else?

--
dukester

[Member dukester]

Helpful

Up

0

::

JOY! A guru involved with `mailutils’ at gnu.org replied to me just now:

Make sure /usr/local/lib is listed in your /etc/ld.so.conf (or
any file which is included from it). If not, add it and run ldconfig

Still need the repo education though! 😀 Thanks!!

--
dukester

[Forum Admin anticapitalista]

Helpful

Up

1

::

Since you are running antiX-19 series (based on Debian buster), only use buster repos.

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Member dukester]

Helpful

Up

0

::

👍

--
dukester

[Anonymous]

Helpful

Up

0

::

Why would compiling a latest version of a program – from git or wherever – break on a Debian-based distro if that tarball etc

Visit this page https://packages.debian.org/buster/mailutils
and note (right-side column) Download Source Package:
[mailutils_3.5-4.dsc]
[mailutils_3.5.orig.tar.xz]
[mailutils_3.5-4.debian.tar.xz]

When you build from a non-debian sourced tarball, its content is probably the equivalent of (only) the “orig.tar.gz” file.
By convention, Debian’s amendments are contained within the separate *debian.tar.gz file.
If you would download (from the linked page, above) orig + debian tarballs, then copy the extracted content of the latter debian file
to a subdirectory named “debian” into the tree of the former… you would then have the necessary, cumulative, “tarball etc” source files.

The plaintext .dsc file contains metadata describing the debian “Build-depends” (and/or Depends,Conflicts,Replaces, et al) relationship with other packages. The details within the dsc file are consulted when you (or a buildhelper utility) perform a “sudo apt-get build-dep mailutils” operation (ref: https://wiki.debian.org/BuildingTutorial#Get_the_build_dependencies). Within the *debian.tar.xz file, a file named “control” similarly provides these details.

If you visit https://packages.debian.org/buster/mailutils-common you will notice that its source package is identical to that of the “mailutils” package. As indicated via the “Binary:” line within the .dsc file(s), and the “Provides:” line within the debian/control file(s), when “mailutils” is built [[[ via pbuilder, or dpkg-buildpackage ~~ not simiply “make install” ]]] MULTIPLE separate packages, including “mailutils-common” are generated. The binaries within the generated mailutils-common will link against identical versions of dependent libraries

The “inxi -r” output shown in your post list zero “deb-src” entries. I can’t guess which *.dsc (for which suite), if any, would have been consulted when gathering the prebuilt dependent packages.

You might (as an exercise toward understanding “what has gone wrong”) visit https://packages.debian.org/bullseye/mailutils, download the *.dsc and *debian.tar.gz files applicable to the bullseye suite… and diff them against those from/for the buster suite. Across debian releases, the interdependent details change ~~ sometimes discrete packages disappear (are “Provided:” by some other source package); sometimes [for reasons] a *.dsc file will spec an exact version, or different version, for some dependent package.

Per the installation error message in your post, the “mailutils” package you are attempting to install does, necessarily, demand a specific-versioned “mailutils-common” package. Whoops, in this scenario where your system has repository entries active for various/multiple suites… per the apt preferences configured on your system, the apt dependency solver is stymied by “apt: install the highest/newest version available” vs “dpkg: installation instructions within this package demands exactly version XYZ”.

The above attempts to address multiple issues intertwined within the given question
” Why would compiling a latest version of a program – from git or wherever – break on a Debian-based distro if that tarball etc”
When building a package for debian, we must ensure “that tarball” does, indeed, contain the necessary “debian-specific et cetera” and that the “et cetera” is matched to the suite used by the intended target machine. Although “building a package” using mismatched deb-src sources may succeed, and might even produce binary executable(s) identical to the expected result… package installation may fail (or runtime quirks/failure may occur) due to mismatched “et cetera” details (for instance: injection of debconf rules, execution of pre/post-install scripts)

[Anonymous]

Helpful

Up

0

::

That “wall of text” above fails to cover an additional important detail related to self-building a package.
In this case, multiple (version-matched) packages will generated. In order for the apt resolver to properly register the status quo, installation of the locally-resident “mailutils-common” must precede installation of the locally-resident “mailutils” package.
.
.
.
sudo apt install /path/to/my_mailutils-common
### then
sudo apt install /path/to/my_mailutils

[Member dukester]

Helpful

Up

0

::

Thanks for the coaching! Lot’s of info to digest. Will walk through it when I’m fully awake, in a calmer mood, and before the snow starts to fly. 😀
Much obliged for all the detail. As a start, I’ve fixed synaptic to use only “buster” repos.

--
dukester

[Author]

Posts