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]>: > 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-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 > > -- > A list of frequently asked questions is available at: > http://wiki.panotools.org/Hugin_FAQ > --- > You received this message because you are subscribed to the Google Groups > "hugin and other free panoramic software" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/hugin-ptx/86b8821a-479b-7b8b-1619-43df02b157c1%40yahoo.com > . > -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CAGARPpum-HOMH9QqtFxwD%3DjYwsEoq%3DMvPAcJKQTsiE6uQHLhhg%40mail.gmail.com.
