| fungi | i think that may be related to the bits of discussion on the openstack-discuss ml about when rdo will finish their packaging | 00:00 |
|---|---|---|
| clarkb | Do you have a subject for that thread or a link? I'm failing to find it | 00:02 |
| clarkb | but yes that seems likely | 00:03 |
| clarkb | the testing repos do seemto have packages, but I'm not sure we should rely on those | 00:04 |
| fungi | i don't recall what it was, no | 00:04 |
| clarkb | we'd also need to more manually configure yum/dnf to use them as there doesn't appear to be an easy mode alias | 00:04 |
| fungi | was just in the past couple of weeks though | 00:04 |
| clarkb | fungi: 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 sorted | 00:08 |
| clarkb | I 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 packages | 00:09 |
| clarkb | that may be a good reason to not do that | 00: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: https://opendev.org/openstack/pyeclib/commit/45299ec4 | 00:12 |
| *** timburke__ is now known as timburke | 00:12 | |
| clarkb | timburke: 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 yet | 00:12 |
| clarkb | I don't think its anything for you to do on your end other than maybe pester people if this is important :) | 00:12 |
| clarkb | I'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 wheels | 00:13 |
| timburke | ah... i've also been working on making it so pyeclib wheels could actually be useful -- see https://review.opendev.org/c/openstack/pyeclib/+/817498 | 00:13 |
| timburke | i'm not sure how to go about getting them published once i've got them, though | 00:14 |
| clarkb | oh neat so you can publish straight to pypi and then we wouldn't need to build them locally | 00:14 |
| timburke | it'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 https://wheels.burke.storage.tburke.duckdns.org/pyeclib/ | 00:15 |
| fungi | publishing wheels of pyeclib wouldn't be hard, but it won't be possible using openstack's present release automation without some additional development invested | 00:15 |
| fungi | i think we already have manylinux1 wheel builder jobs for pyca/cryptography's arm64 wheel builds | 00:16 |
| clarkb | fungi: we do but I think they still manually publish things? | 00:16 |
| fungi | right, but "publish things" is really just give twine some credentials and run it | 00:17 |
| timburke | if 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, though | 00:17 |
| fungi | thing 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 |
| fungi | in fact, if we want multiple processor architectures, we almost definitely need to do the latter | 00:19 |
| fungi | since we won't easily be able to build x86-64 and aarch64 wheels in the same nodeset | 00:19 |
| clarkb | fungi: you can using the same system that we use to build arm docker images for nodepool | 00:19 |
| clarkb | it might be very slow | 00:19 |
| fungi | though we *could* push them separately to pypi too | 00:19 |
| fungi | but pushing the wheels and sdist all at the same time is much nicer to users | 00:20 |
| clarkb | ++ and pushing wheels before sdists if you can't is better | 00:20 |
| timburke | i'm not too worried about slow -- we don't exactly make a lot of pyeclib/liberasurecode releases | 00:20 |
| clarkb | timburke: the buildx stuff in docker can use qemu to emulate various arches it is slow due to the emulation | 00:21 |
| clarkb | what we found is that compiles in particular are slow but I don't imagine that code base is too large | 00:21 |
| fungi | good point, we could do emulated builds and for pyeclib that's probably not going to be terrible | 00:22 |
| timburke | well, i'd *like* to also include isa-l if i can... might grow the compile a bit | 00:22 |
| timburke | (the RS algo included with liberasurecode is *slow* -- for non-development environments, you almost always want intel's version) | 00:23 |
| clarkb | is that something that relies on SSE or similar? if so you won't get it on arm anyway | 00:25 |
| clarkb | you can do the x86 builds natively without much trouble | 00:25 |
| clarkb | anyway dinner time now. | 00:26 |
| timburke | good 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 mazzy50988129295808594 | 01:53 | |
| opendevreview | Merged openstack/project-config master: Replace old Yoga cycle signing key with Zed https://review.opendev.org/c/openstack/project-config/+/837174 | 10:06 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!