bryceml
commented
3 years ago Which repo did you have configured that this is pulling from? or rather, what does your .repo file look like?
Closed whytewolf closed 3 years ago
bryceml
commented
3 years ago Which repo did you have configured that this is pulling from? or rather, what does your .repo file look like?
whytewolf
commented
3 years ago ugh, thanks. I thought I had already switched to saltproject. apparently I did not on this host
[salt-py3-latest]
name=SaltStack Latest Release Channel Python 3 for RHEL/Centos $releasever
baseurl=https://repo.saltstack.com/py3/redhat/7/$basearch/latest
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/saltstack-signing-key, file:///etc/pki/rpm-gpg/centos7-signing-keyhumm, nope switching to saltproject and uninstalling and reinstalling that debuginfo and gdb still gives the same errors
bryceml
commented
3 years ago btw, going forward, I've been just copying the rpms from epel directly rather than re-compiling them from source rpms. The only thing I do is re-sign them.
https://repo.saltproject.io/salt_rc/py3/redhat/7/x86_64/
I wasn't planning on copying the respective debug rpms or source rpms for ones directly copied from epel, assuming people could just grab epel's copies of those if they wanted them.
Is that going to be an issue?
bryceml
commented
3 years ago looks like python36-zmq in our repos is a newer version that is not in epel for centos 7, so this is a legitimate problem I need to look into. Hopefully in time for 3003.1.
while trying to use GDB to determine what is happening with a weird segfault. I have gdb complaining that the debug info for zmq does not match file files correctly.