seongsoocho | Hi timburke , I try to upgrade liberasurecode . I downloaded the source code of liberasurecode (1.6.2) and build, installed in my proxy server. After that, I run a command `python3 -c 'import pyeclib.ec_iface as ec; print(ec.LIBERASURECODE_VERSION)` but, It said the version is 1.4.0 . ( liberasurce code already installed with apt, 1.5.0) Am I missing something? | 04:40 |
---|---|---|
opendevreview | Matthew Oliver proposed openstack/swift master: wip: shard replication sync points https://review.opendev.org/c/openstack/swift/+/905064 | 07:25 |
opendevreview | Yan Xiao proposed openstack/swift master: stats: API for native labeled metrics https://review.opendev.org/c/openstack/swift/+/909882 | 13:56 |
clarkb | seongsoocho: your pyeclib installation may link against a specific version of liberasurecode. You may need to rebuild pyeclib with the updated liberasurecode installed | 15:23 |
seongsoocho | oh.. I relinked all symlink of liberasurecode in /lib, /usr/lib but.. I should rebuild pyeclib too.. | 15:25 |
timburke | seongsoocho, that's really strange! since pyeclib 1.5.0, it should get the liberasurecode version dynamically (see https://github.com/openstack/pyeclib/commit/47493a0f), provided liberasurecode>=1.5.0 (see https://github.com/openstack/liberasurecode/commit/09d8bbf3) | 15:25 |
timburke | what version of pyeclib is it? was it from apt, too? | 15:25 |
timburke | you might try running `ldd $(python -c 'import pyeclib_c; print(pyeclib_c.__file__)')` to see what pyeclib is looking at | 15:26 |
seongsoocho | pyeclib also from apt. | 15:29 |
seongsoocho | okay I will try it soon | 15:29 |
timburke | so presumably 1.6.0 | 15:31 |
timburke | and it can't be that the link to liberasurecode is *completely* broken, or you'd get something like "ImportError: liberasurecode.so.1: cannot open shared object file: No such file or directory" | 15:37 |
seongsoocho | The version of python3-pyeclib from apt is 1.3.1-1ubuntu3 | 15:40 |
seongsoocho | and.. the result of ldd said "liberasurecode.so.1 => /usr/lib/x86_64-linux-gnu/liberasurecode.so.1" | 15:40 |
seongsoocho | and that so.1 file is.. | 15:41 |
seongsoocho | lrwxrwxrwx 1 root root 23 May 13 12:03 /usr/local/lib/liberasurecode.so.1 -> liberasurecode.so.1.6.2 | 15:41 |
clarkb | that pyeclib version is too old to autodetect accordign to what timburke said above | 15:44 |
clarkb | its also possible that in the future distro packaging would remove autodetection to force use of the distro packaged lib? I have no evidence they have done this | 15:44 |
seongsoocho | I'm using ubuntu 18.04 for proxy-server.. then I will try to upgrade pyeclib over 1.5.0 | 15:46 |
timburke | ah, yep -- pyeclib 1.3.1 would continue to report the version of liberasurecode it was built against rather than what's available at runtime. it should still be running the upgraded code, though -- you could probably write a test frag then read back the version from it to verify | 16:01 |
seongsoocho | timburke , clarkb thanks for helping me. after I upgraded pyeclib to 1.5.0, pyeclib can use liberasurecode 1.6.2 | 16:11 |
opendevreview | Merged openstack/swift master: backend ratelimit: support per-method rate limits https://review.opendev.org/c/openstack/swift/+/840542 | 16:11 |
opendevreview | Jianjian Huo proposed openstack/python-swiftclient master: Add reset function for ReadableToIterable https://review.opendev.org/c/openstack/python-swiftclient/+/918701 | 18:17 |
timburke | oh yeah, i still need to figure out how to take the build artifacts from something like https://zuul.opendev.org/t/openstack/build/a8e195bfe57b4d2c928d1a52a0523e4e/artifacts and use them in the release job... | 19:05 |
clarkb | timburke: the opendev container image build jobs may be useful for that. We build and publish images in the gate then if that results in merging a post merge job promotes those artifacts | 19:46 |
clarkb | I think you can do similar with release jobs instead of post jobs | 19:46 |
opendevreview | ASHWIN A NAIR proposed openstack/python-swiftclient master: support part-num in python swiftclient https://review.opendev.org/c/openstack/python-swiftclient/+/902020 | 20:22 |
opendevreview | ASHWIN A NAIR proposed openstack/python-swiftclient master: Fix upload with "parent-relative" file paths https://review.opendev.org/c/openstack/python-swiftclient/+/280312 | 20:35 |
timburke | clarkb, does pypi have the same concept of "promoting" a release? and i certainly wouldn't want every commit off master to show up on https://pypi.org/project/pyeclib/#history -- maybe there's something we could do with https://test.pypi.org/ ? | 21:44 |
timburke | or maybe i should look at writing a custom release-pyeclib-python job that inherits from release-openstack-python but also builds wheels the way i need... | 21:44 |
clarkb | I don't think so. pypi is far more static about things to prevent people from replacing one thing with another nefariously | 22:09 |
clarkb | but you could publish to tarballs and then promote that maybe | 22:10 |
opendevreview | Shreeya Deshpande proposed openstack/swift master: HybridMultiObjectDispatcher https://review.opendev.org/c/openstack/swift/+/915483 | 23:06 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!