This happens more often with manually installing debian packages.
So you do a "sudo dpkg -i lux-<version>.dpkg" and get this error.
What you now should do is a:
"sudo dpkg --configure -a"
followed by:
"sudo apt-get -f install"
That should fix it.
And if you had done a simple DuckDuckGo/Google search, you would have
found that as well as it is as old as the world (well, almost as old).
This could be solved by creating a flatpack or appimage which has
everything "inside".
Harry
Op za 5 jun. 2021 om 10:37 schreef 'Kay F. Jahnke' via hugin and other
free panoramic software <[email protected]
<mailto:[email protected]>>:
Am 05.06.21 um 05:31 schrieb David W. Jones:
> Well, here's what happened when I tried to install it here on
Debian 11:
>
> Preparing to unpack lux-1.0.9-0git-Linux.deb ...
> Unpacking lux (1.0.9-0git) ...
> dpkg: dependency problems prevent configuration of lux:
> lux depends on libc6 (>= 2.29); however:
> Version of libc6:amd64 on system is 2.28-10.
> lux depends on libexiv2-27 (>= 0.25); however:
> Package libexiv2-27 is not installed.
> lux depends on libgcc-s1 (>= 4.0); however:
> Package libgcc-s1 is not installed.
> lux depends on libstdc++6 (>= 9); however:
> Version of libstdc++6:amd64 on system is 8.3.0-6.
> lux depends on libvigraimpex11 (>= 1.11.1+dfsg); however:
> Package libvigraimpex11 is not installed.
>
> dpkg: error processing package lux (--install):
> dependency problems - leaving unconfigured
> Errors were encountered while processing:
> lux
Thanks for reporting back!
The dependencies are the same as they have been throughout lux 1.0.8;
this issue is not new with 1.0.9:
I've probably misled you by simply stating that I made a 'debian
package': I develop lux on ubuntu, here I use ubuntu ubuntu 20.04.2
LTS,
which should differ quite a bit in the set of packages and their
versions to your debian 11, which is also quite brand-new and has not
been released yet. What surprises me is that dpkg can't get hold of
common packages like libexiv2, libgcc and libstdc++, but these may be
naming problems, where the ubuntu naming scheme differs from
debian's.
In general, you can't rely on ubuntu-built packages to run on debian.
I'll change the name of the packages I offer for download to make
clear
what the target distro is, to help other users avoid this pitfall. As
far as ubuntu goes, basing on 20.04 LTS is quite conservative, and
the
dependencies should work on newer non-LTS distros as well - ubuntu
users, please report back! For now, there are two debian packages
I can
offer:
https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0-debian10-i32.deb
<https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0-debian10-i32.deb>
https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0git-ubuntu20.04-amd64.deb
<https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0git-ubuntu20.04-amd64.deb>
As you can see, the debian 10 package is 32 bits - I currently don't
have a 64bit install of debian 10 handy, but I just did the CMake
build
here on the debian10 32bit system to verify that it builds and
installs
without problems, so I thought I might as well put it up for
download.
The ubuntu20.04 amd64 package is the same as what I had offered
before
as the 1.0.9 'Linux' package, only with a clearer name. Sorry for the
confusion.
How about you build a debian package on your machine? Then we can
have a
look at what your system puts into the .deb. Just follow the steps in
'Building lux with cmake' given on the bitbucket page. Then I can put
your package online if you like, to help other debian 11 users. To
build
a debian package, you have to invoke cmake with -DCPACK_BINARY_DEB=ON
during cmake configuration, and to build the package you have to say
'make package'.
Are you dd or involved with the debian project? How about you help
bringing lux to debian? With an actively maintained lux package on
debian, we might rely on it trickling down to ubuntu and other
debian-based distros - I've done this successfully with the vspline
debian package, but that's already quite a bit of work, and I've
shunned
going through the laborious process for yet another package -
especially
as I don't have dd status and have to bother my mentor whenever I
have a
new version.
@Kornel: Is there a way to provide 'linux bundles' which include all
shared libraries, as I make them for the Windows stickware
version? Can
CMake output flatpak or a similar format which works on more distros?
The CMake package build produces a package named
'lux-1.0.9-0git-Linux.deb', can we influence the naming of the
package?
It might be good to have 'ubuntu' or 'debian' in the package name
rather
than 'Linux', and also the version, like 20.04, and the architecture,
like amd64 - I've done the naming of the two packages I just put
up for
download manually.
Kay
