[18:40:58] hey, what does `"dt": "-"` mean in centrallog's sampled-1000.json? like I assume the timestamp isn't available, but how does that happen? [18:53:03] rzl: I don't know the answer, but I remember we hit that during some incident and had that listed as an question or action item [18:53:12] and, since the file seems to be roughly in chronological order, can I copy the timestamp from the entry before it and assume it's correct to within a few seconds? or does that not turn out to be true [18:53:15] legoktm: hm, okay [19:34:47] Does anyone know about pycryptodome vs 'import Crypto'? Docs suggest that pycryptodome is the replacement implementation for pycrypto and so should provide the Crypto libraries but on Bullseye it seems not to. [19:38:30] `dpkg-query -L python3-pycryptodome` only shows a module named Cryptodome, not one named Crypto :/ [19:38:56] I've ran into this before [19:39:07] python3-cryptodome is cryptodomex, which is the same package but under the Cryptodome name [19:40:12] I'm tempted to just symlink 'Crypto' to 'Cryptodome' but that's surely not what all these other happy forum users are doing... [19:40:25] this is https://bugs.debian.org/886291 [19:40:32] where are you seeing breakage? [19:41:10] oh dang [19:41:38] taavi: Anytime I try to 'import Crypto' on cloudcontrol2003-dev (and presumably anywhere with Bullseye) [19:41:54] yes, but what's trying to do that? backy2? [19:42:03] sadly, I think the easiest thing to do would be to adjust your code to use 'import Cryptodome' [19:42:34] taavi: yes, backy2 [19:42:49] but surely not /only/ backy2? Seems like this will break a million python tools [19:44:19] paravoid: This is debian-only, right? So fixing the upstream backy2 code would just break it every-not-bullseye? [19:45:20] andrewbogott: not necessarily -- if you adjust the dependency in requirements.txt (or whatever alternative) to pycryptodomex [19:45:24] (the x is not a typo) [19:45:46] https://pypi.org/project/pycryptodomex/ vs. https://pypi.org/project/pycryptodome/ [19:45:55] same code, one under the Cryptodome namespace, the other one under the Crypto namespace [19:46:18] Except on Debian where they're exactly the same? [19:46:27] (both under Cryptodome I mean) [19:46:56] Debian doesn't have pycryptodome at all, it only has pycryptodomex, packaged as python3-pycryptodome [19:47:30] So if i change the dependencies for backy2 to pycryptodomex then it won't work on debian... [19:47:44] I guess maybe requirements.txt and debian dependencies are disjoint enough that I can have it both ways [19:47:54] they are [19:48:00] * andrewbogott will start by trying a hotfix [19:48:11] ok -- I'll see what I can do! thank you [19:48:24] np, it's a confusing situation, I've been bitten by it before myself [19:49:10] It seems like a straightforward bug in Debian that should be fixed, but I guess there must be more to it than that [19:49:55] I think the issue is that pycryptodome is overriding the namespace of another package (crypto) [19:50:31] In my case the issue is that it isn't overriding it :) [19:50:48] it's a fork, so the maintainer opted in just using the version where it has its own separate namespace [19:53:12] https://phabricator.wikimedia.org/T301909 [19:53:58] I don't understand how 'removing Crypto and not replacing it and breaking every python tool that imports it' is a good decision but I can live with it. I guess no one in the 'real world' runs python outside of a venv anyway. [19:54:52] * andrewbogott needs to run but will start hacking around this on return