Re: Slic3r --gui won't run
On Sun 19 Jul 2020 at 11:55:05 (-0400), Gene Heskett wrote:
> On Sunday 19 July 2020 09:56:10 Reco wrote:
> > On Sun, Jul 19, 2020 at 09:45:41AM -0400, Gene Heskett wrote:
> > > Looks like my apt/sources.d is not uptodate?
> >
> > Looks like it is. Because [1] shows libwx-perl, and it's a real
> > package.
> >
> > [1] https://packages.debian.org/stretch/libwx-perl
>
> I found a page that shows what my sources.list should look like, made it
> so, but still can't install libwx-perl because there is not a
> perl-api-5.24.1 and a matching lib. If this is a dependency of slic3r
↑ lose that hyphen.
Package: perl-base
Source: perl
Version: 5.24.1-3+deb9u6
Essential: yes
You must have this.
Provides: libfile-path-perl, libfile-temp-perl, libio-socket-ip-perl, libscalar-list-utils-perl, libsocket-perl, libxsloader-perl, perlapi-5.24.1
On Sun 19 Jul 2020 at 14:30:54 (-0400), Gene Heskett wrote:
> On Sunday 19 July 2020 13:38:22 Andrei POPESCU wrote:
> > On Du, 19 iul 20, 12:47:45, Gene Heskett wrote:
> > > Did that Andrei, updated apt-get, apt-get now gives a reason.
> > > Depends on 2 more packages, but adding them to the apt-get install
> > > line gets this:
> >
> > If APT can't find a solution adding more packages to the install line
> > won't help.
> >
> > > The following packages have unmet dependencies:
> > > libalien-wxwidgets-perl : Depends: libwxgtk3.0-dev (< 3.0.3~) but
> > > 3.0.4+dfsg-4~bpo9+1 is to be installed
> > > Depends: libwxgtk-media3.0-dev (< 3.0.3~)
> > > but 3.0.4+dfsg-4~bpo9+1 is to be installed
> > > E: Unable to correct problems, you have held broken packages.
> > >
> > > I'm about out of patience for the day. I have been screwing with
> > > this since about 5AM, and its now 12:45 local. And I am damned
> > > tired of apt-gets inability to name the package thats breaking it.
> >
> > Considering how your sources.list looked like there's a non-zero
> > probability your system is in an inconsistent state due to packages
> > from stretch-backports that shouldn't be there.
> >
> > The easiest way to find all installed packages from backports is to
> > run
> >
> > aptitude search '?narrow(?installed,?archive(backports))'
> >
> >
> > Yes, I know you wrote you don't trust 'aptitude', this is just a
> > search :)
>
> that spits out about 3 or 4 lines of text and blanks it, in about 100
> millisecs, and will not redirect to |less. No line feeds IOW. I don't
> read at 20k wpm, so I've no clue what its trying to tell me.
Nothing at that point; it's just building indices.
BTW you could find that out by running script before the command,
and looking at ./typescript afterwards. In fact, you might save a lot
of time and effort when you're individualistically configuring your
systems by always running script. Because ./typescript gets
overwritten each time, I wrap it:
scrip is a function
scrip ()
{
script "typescript-$HOSTNAME-$(date +%Y-%m-%d-%H-%M-%S)-$1"
}
$ dpkg -l | grep '\<bpo'
will likely give you a list of your backports as you don't trust aptitude.
Cheers,
David.
Reply to: