[10:33:32] <volans>	 XioNoX, moritzm: I'm looking for advice. So homer builds the wheels within a docker image based on our debian buster that ships an old pip. In order to get a binary wheel I need to upgrade pip within the image, but that's what pip says to never do (upgrade distro pip). That's what cryptography build instructions says though. If I don't it will compile it from scratch within the docker, 
[10:33:38] <volans>	 that means installing all the ...
[10:33:41] <volans>	 ... cryptography dependencies, that now include rustc, cargo and I'm still finding out which other
[10:33:50] <volans>	 upgrading pip within the docker works fine FWIW
[10:34:55] <volans>	 how bad would be this option? if not acceptable/bad I'll go on finding all the required deps
[10:36:09] <volans>	 I'm testing one more time with the listed deps
[10:43:28] <moritzm>	 depends on whether other build environments will be in the same position, if there are potentially other images which run into the same situation it might make sense to build pip 20 for buster in a component (or even buster-backports), if it's just a one off I'd rather upgrade within the image
[10:43:42] <moritzm>	 since it's just used for the wheels build anyway
[10:45:00] <volans>	 anyone that will have cryptography as a dependency, either directly or indirectly
[10:45:39] <volans>	 and yes it's still failing with the deps, some obscure cargo error building ghost with an empty backtrace (all unknowns)
[10:46:09] <volans>	 the upgraded pip is at runtime, so just used for the building, is not part of the base python build image in my patch
[10:48:26] <volans>	 I'll add you to the patch so you can comment there
[10:57:17] <volans>	 {sent} https://gerrit.wikimedia.org/r/c/operations/software/homer/deploy/+/683256
[10:58:59] <moritzm>	 ack, I'll have a look in a bit
[10:59:31] <volans>	 thx, no hurry
[17:45:42] <volans>	 wrt the ganeti guidelines, we just got a request of 64G RAM instances... :)
[18:24:51] <moritzm>	 yeah, I'll reply tomorrow