Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ERROR: No valid Python version
While on the topic of pkg_rr, if I'm permitted to cut in, I have been
getting strange errors suggesting a problem with the topological order
of replacement perhaps:
---
===> Building binary package for libxslt-1.1.38nb1
=> Creating binary package /usr/pkgsrc/packages/All/libxslt-1.1.38nb1.tgz
===> Installing binary package of libxslt-1.1.38nb1
pkg_add: A different version of libxslt-1.1.38nb1 is already
installed: libxslt-1.1.38
pkg_add: 1 package addition failed
*** Error code 1
....
The test run of 'pkg_chk -uq' has identified libxslt as a target for
upgrade, but it is for some reason missing from the final list of
installed packages as found by it, so it tries to install it instead
of replace.
This is done after 'pkgin ar', 'pkg_admin rebuild-tree', 'pkg_admin
rebuild' and the above. I was running 'pkg_rolling-replace -suv' at
the time.
So it's manual replace and restart - again.
Chavdar
On Wed, 30 Aug 2023 at 14:59, Greg Troxel <gdt%lexort.com@localhost> wrote:
>
> Riccardo Mottola <riccardo.mottola%libero.it@localhost> writes:
>
> > Hi,
> >
> > Greg Troxel wrote:
> >> did you cd to devel/scons (or really the PKGPATH of the installed pkg)
> >> and type "make replace". The pkg_rr man page says, or should say, to do
> >> that, and then to deal with that error as if it were not from pkg_rr.
> >
> > no, I didn't... I thought to have encountered some weird setup
> > error. I did now. It fails with a cryptic message:
>
> the man page for pkg_rr asks that people not report "some make replace
> that pkg_rr did failed" as a pkg_rr problem, because it's not really
> true but mostly because the subset of peopel that don't like pkg_rr then
> ignore your report, whereas some of them could perhaps be helpful if it
> is properly reported as a simpler failure.
>
> >> perhaps, scons 3 is now limited to py27.
> >
> > Well it is trying to build the py27 version, also it is more "sane
> > now" since it says:
> > py27-scons-3.1.2nb7while with pkg_rr it was confused between the py310
> > and the "none" version:
> >
> > RR> Replacing py310-scons-3.1.2nb4
> > ===> Cleaning for none-scons-3.1.2nb7
> >
> > In fact at the moment I have this one installed, according to pkg_info
> >
> > py310-scons-3.1.2nb4 Python-based, open-source build system
> >
> > so I suppose pkg_rr was right trying to subdtitute the py3 version
>
> Yes, the basic issue is that new scons3 dropped support for py3, and the
> basic solution is to upgrade to 4, but we don't really have support for
> that, and 99% people only have scons as a build tool (because somebody
> else wrongly thought it was better than autoconf 5 years ago :-).
>
> >> I recommend "pkgin ar" before a rebuild run.
> >
> > Now it is a little late :-P
>
> You can still do it and continue. Unless you actually *want* scons3,
> removing it is best. The tools that are needed for other things will
> get built.
>
--
----
Home |
Main Index |
Thread Index |
Old Index