If I remember well this is the 3rd time I'm having an issue with this hidden #passlib #ansible requirement, but every time it's a different cause. First it took me some time to figure out that the error message was about the controller machine, not the hosts. But I only found the next day it was because of a ghost ansible installation, I had to manually clean up...

https://forum.ansible.com/t/ansible-cannot-find-passlib-when-creating-a-user-through-github-action/7874/13

#devops

Ansible cannot find passlib when creating a user through Github Action

Thank you for the explanation, that’s helps

Ansible

Essentially, distro developers are firefighters, putting out fires made by careless upstreams.

What I've wasted time on, today:

- making the non-standalone test suite of #Hatchling (sigh) work without #UV again, so that a critical build dependency of a growing number of #Python packages could be tested everywhere

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cc6e54e1df5e0802198c793f39107a9028b8698f
https://bugs.gentoo.org/930662

- fixing effectively dead (but with a promise of revival) #PassLib not to break random stuff via printing warnings when using newer #BCrypt versions

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c1e015b65b74283a51893672739c5e4784b95273
https://bugs.gentoo.org/925289

- hacking the test suite of #ImageIO work using an offline copy of test data, rather than cloning its git repository at the beginning of tests

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=77ff4bc09d68067f2c635d43d446f308990e0873

I really wish people would consider donating to distro developers more often, rather than to projects that create this thankless work for us.

#Gentoo

repo/gentoo.git - Official Gentoo ebuild repository

Browse the Gentoo Git repositories

W gruncie rzeczy, devowie distro są jak strażacy, walczący z pożarami wywołanymi przez nieostrożnych twórców oprogramowania.

Dzisiaj zmarnowałem czas na:

- naprawienie testów systemu budowania #Hatchling (które nie są wyodrębnione od testów Hatcha, wzdych), by działały znów bez #UV, abyśmy powtórnie mogli wszędzie testować tę krytyczną zależność rosnącej liczby paczek Pythona

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cc6e54e1df5e0802198c793f39107a9028b8698f
https://bugs.gentoo.org/930662

- naprawianie praktycznie martwej (ale z obietnicą resuscytacji) biblioteki #PassLib, by nie psuła przypadkowych paczek, wypisując ostrzeżenia z nowszymi wersjami biblioteki #BCrypt

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c1e015b65b74283a51893672739c5e4784b95273
https://bugs.gentoo.org/925289

- obchodzenie upierdliwości w #ImageIO tak, by dało się tę bibliotekę testować offline, z pobranymi wcześniej danymi, zamiast przy każdym uruchomieniu testów klonować repozytorium git

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=77ff4bc09d68067f2c635d43d446f308990e0873

Naprawdę chciałbym, by ludzie częściej rozważali wsparcie devów distro, a nie tylko projektów, które tworzą im tę niewdzięczną pracę.

#Gentoo

repo/gentoo.git - Official Gentoo ebuild repository

Browse the Gentoo Git repositories

I wonder who maintains `passlib` these days? Seems it does not play well with `bcrypt`.

Found this out bringing up a deployment with Ansible, since it uses `passlib` to support lots of hashes, and parts of our stack use `bcrypt` hashing. (Yes, I'd prefer `scrypt` or `argon2id`, but apparently I'm clueless about these things.)

Nice little land mine to go bang on a Friday.

https://bugs.gentoo.org/925289

#python #passlib #bcrypt #ansible

925289 – dev-python/bcrypt-4.1.[12] breaks bcrypt support in dev-python/passlib-1.7.4-r2 (and by extension, ansible)

#踩坑 #passlib #python 趁着迁移服务器重跑一遍手里的部署脚本(一个创建兼容 htpasswd 密码的工具),发现脚本出现了 crypt 包的弃用告警,于是就更新了下换成了 passlib ,原本使用的 sha512 的 hash 算法,换过去后没仔细看计算的轮次就直接开跑了,全部替换后就发现做网关的 nginx 的 CPU 资源能吃满,于是逐一排查配置,最后排查到密码,换成之前创建的配置才恢复正常,对比之后才发现默认 passlib 创建密码的运算轮次有6万多次,每个 HTTP 请求 nginx 都要计算一编......

还好不是核心业务,只是个日志收集的服务......