Saturday, 2022-04-09

fungii think that may be related to the bits of discussion on the openstack-discuss ml about when rdo will finish their packaging00:00
clarkbDo you have a subject for that thread or a link? I'm failing to find it00:02
clarkbbut yes that seems likely00:03
clarkbthe testing repos do seemto have packages, but I'm not sure we should rely on those00:04
fungii don't recall what it was, no00:04
clarkbwe'd also need to more manually configure yum/dnf to use them as there doesn't appear to be an easy mode alias00:04
fungiwas just in the past couple of weeks though00:04
clarkbfungi: we never made the wheel builds best effort right? because I guess that would be anbother way around this. Let the pyeclib wheel build fail until they get the devel package sorted00:08
clarkbI wonder if there are downsides to that like getting packges out of sync with each other and then pip will try to do the sdist locally and fail due to lack of local devel packages00:09
clarkbthat may be a good reason to not do that00:09
timburke__what about pyeclib wheel builds? i know we had to consciously *stop* doing that as part of test-release etc. not so long ago:
*** timburke__ is now known as timburke00:12
clarkbtimburke: we're trying to spin up a wheel mirror for centos 9 and currently failing to install liberasurecode-devel for pyeclib because centos-release-openstack-yoga doesn't quite exist for centos 9 yet00:12
clarkbI don't think its anything for you to do on your end other than maybe pester people if this is important :)00:12
clarkbI'm just trying to think through if it is even possible to not build pyeclib wheels in the meantime and I suspect it is fine for pyeclib but not in the general case for other wheels00:13
timburkeah... i've also been working on making it so pyeclib wheels could actually be useful -- see
timburkei'm not sure how to go about getting them published once i've got them, though00:14
clarkboh neat so you can publish straight to pypi and then we wouldn't need to build them locally00:14
timburkeit's that "you can publish straight to pypi" part where things fall down currently ;-) if you want a preview, though, try out the wheels at
fungipublishing wheels of pyeclib wouldn't be hard, but it won't be possible using openstack's present release automation without some additional development invested00:15
fungii think we already have manylinux1 wheel builder jobs for pyca/cryptography's arm64 wheel builds00:16
clarkbfungi: we do but I think they still manually publish things?00:16
fungiright, but "publish things" is really just give twine some credentials and run it00:17
timburkeif you give me some pointers on where that development needs to happen, i'm happy to give it a try. not sure how best to test any infra-oriented patches locally, though00:17
fungithing is we'd either need to extend the openstack release jobs to do the manylinux1 wheel builds, or more likely run that as a parent job and then have the release job just fetch and push the resultant artifact(s)00:18
fungiin fact, if we want multiple processor architectures, we almost definitely need to do the latter00:19
fungisince we won't easily be able to build x86-64 and aarch64 wheels in the same nodeset00:19
clarkbfungi: you can using the same system that we use to build arm docker images for nodepool00:19
clarkbit might be very slow00:19
fungithough we *could* push them separately to pypi too00:19
fungibut pushing the wheels and sdist all at the same time is much nicer to users00:20
clarkb++ and pushing wheels before sdists if you can't is better00:20
timburkei'm not too worried about slow -- we don't exactly make a lot of pyeclib/liberasurecode releases00:20
clarkbtimburke: the buildx stuff in docker can use qemu to emulate various arches it is slow due to the emulation00:21
clarkbwhat we found is that compiles in particular are slow but I don't imagine that code base is too large00:21
fungigood point, we could do emulated builds and for pyeclib that's probably not going to be terrible00:22
timburkewell, i'd *like* to also include isa-l if i can... might grow the compile a bit00:22
timburke(the RS algo included with liberasurecode is *slow* -- for non-development environments, you almost always want intel's version)00:23
clarkbis that something that relies on SSE or similar? if so you won't get it on arm anyway00:25
clarkbyou can do the x86 builds natively without much trouble00:25
clarkbanyway dinner time now.00:26
timburkegood point. i seem to remember doing some benchmarks on arm and the intel code still winning out -- i should see if i took notes, and if so, where i put them...00:26
*** mazzy509881292958085945 is now known as mazzy5098812929580859401:53
opendevreviewMerged openstack/project-config master: Replace old Yoga cycle signing key with Zed

Generated by 2.17.3 by Marius Gedminas - find it at!