Python flavors in Synth: Scan of * failed (port deleted), it will not be considered.

A

ahw

I am seeing a similar issue to that reported by this thread:
https://forums.freebsd.org/threads/...port-deleted-it-will-not-be-considered.62392/

The critical difference is that all of the complaint message (from synth upgrade) are referring to an old python flavour that is, as far as I can tell, no longer installed on the system at all.

For example, I get the following complaint about openssl:
Scan of security/py-openssl@py38 failed, it will not be considered.

All of the packages for which there is a complaint are flagged with the old flavor "py38", however the system has been updated to use python 3.9.

Looking at pkg, it does not appear that this port (or any python 3.8 port) is installed:

$ pkg info | grep py3
py39-libxml2-2.10.3 Python interface for XML parser library for GNOME
py39-pygments-2.9.0 Syntax highlighter written in Python
py39-setuptools-63.1.0 Python packages installer

$ pkg info | grep open
libltdl-2.4.7 System independent dlopen wrapper
openjpeg-2.5.0 Open-source JPEG 2000 codec
openssl-1.1.1s,1 TLSv1.3 capable SSL and crypto library
rubygem-asciidoctor-2.0.17 Fast, open source text processor and publishing toolchain
xpdfopen-0.86_1 Command line utility for PDF viewers

Any ideas what is going on?

How does synth decide what packages are installed? I'm guessing that there is some outdated flavour information somewhere that needs a nudge.

I should perhaps add that running "make FLAVOR=py38 uninstall" in the port directory simply generates an error that the port/flavour is not installed.
 
Thank you Alain -- I mustn't have been clear: the problem is not that I have the wrong python version -- the problem is that there seem to still be leftover references to older python packages that are not needed.

As far as I can tell, the packages listed by synth are not installed (presumably why the scan fails) and don't exist on the system at all.

What I am hoping to do is remove reference to these packages from wherever they are being stored to make synth understand that they are gone, and therefore not attempt to process them (and fail).

Python (version 3.9) is working fine. There is no problem with the current python install -- just these odd hangovers from the past version.

Does anyone know from where the list that synth uses to process the package search comes?
 
I had a similar problem (with py39* package leftovers after upgrading to py311*), and I found the below worked for me:

rm /var/synth/live_packages/All/py39-*

Caveat emptor!
 
You must log in or register to reply here.
Back
Top