Am 14.07.26 um 06:52 schrieb Matthias Fechner:
I disabled it now with:
poudriere options -z salt314
devel/py-opentelemetry-exporter-otlp-proto-http
Hit CTRL+c after devel/py-opentelemetry-exporter-otlp-proto-http was
stored.
Build is now fine. I will test it today if I have a waiting gap ;) I
keep you posted.
do you know if some path has changed the master is reading the state files?
I have not used salt now for some time, but it seems that the minion
does not find the state (not the master does).
If I execute on the minion:
salt-call -l debug state.apply common
I see:
...
[DEBUG ] Loading private key [DEBUG ] Loading public key [DEBUG ]
Finished gathering pillar data for state run [INFO ] Loading fresh
modules for state activity [DEBUG ] The functions from module 'jinja'
are being loaded by dir() on the loaded module [DEBUG ] LazyLoaded
jinja.render [DEBUG ] The functions from module 'yaml' are being loaded
by dir() on the loaded module [DEBUG ] LazyLoaded yaml.render [DEBUG ]
Could not find file 'salt://common.sls' in saltenv 'base' [DEBUG ] Could
not find file 'salt://common/init.sls' in saltenv 'base'
The states are existing on the master.
ls -las /usr/local/etc/salt/states/common/ total 0 0 drwxr-xr-x 1
vagrant vagrant 58 Feb 21 11:20 . 0 drwxr-xr-x 1 vagrant vagrant 262 Mar
30 08:30 .. 0 drwxr-xr-x 1 vagrant vagrant 88 Jul 13 10:29 files 0
-rwxrwxrwx 1 vagrant vagrant 780 Feb 2 16:52 init.sls 0 -rwxrwxrwx 1
vagrant vagrant 1428 Nov 21 2025 map.jinja 0 -rwxrwxrwx 1 vagrant
vagrant 689 Nov 23 2025 pkg.sls
I see exactly the same behavior if I execute salt-call from the master.
Is there additional configuration required compared to the older version?
Thanks
Matthias
