[07:09:35] I can't push anything for review - getting error 504? Is something broken with gerrithub? [07:13:01] same here [07:13:05] I can't even get logged in [07:13:17] (to gerrithub that is) [07:16:10] lhodev: I have searched the net and I think there common advice is to make RPM package per distro. So I think this is a solution for missing python3 in some old distros. [07:24:52] pwodkowx: The %dist macro for Oracle Linux expands to ".el7" [07:26:53] I think that may be the same value as for RHEL on which Oracle Linux (OL) maintains compatibility. [07:27:30] hmm... I couldn't find any doc for os specific macros, but you are right. in fedora it expands for .fc28 :P [07:28:37] ok, this might be solution, thanks. I will change it now. [07:32:16] Shuhei: yes, let's wait for repu1sion's update - i suspect he is trying to use the raid bdev module outside of the rest of spdk, without the generic bdev layer [07:36:47] pwodkowx: While we can wrap, I hope, the %Requires with %if's -- there may even be a %ifdist -- to specify either python or python3, that still leaves us with the challenge of resolving the shebangs in the python scripts. You mentioned using sed to accomplish that. I'd like to leave that as a last resort in case we kind of something else that works better than changing the python scripts during installation. [07:37:22] s/kind of/can do/ [07:38:13] I would love to but from Fedora packaging guide: env is banned as well as /usr/bin/python [07:38:29] python2 is deprecated [07:38:53] from other hand, DPDK do sed shebang [07:39:37] If you have some nice workaround for this I'm open [07:40:46] I know that this is not nice to sed scripts but from other side this is not a crime :P [07:41:12] we can make .patch for that if you don't like sed :D [07:41:34] pwodkowx: lol, patch the spec file itself? (shudder) [07:41:53] no, apply patch during rpm build [07:41:55] Or, a .patch to alter all of the *.py's ? [07:41:57] Yeah, got it. [07:44:17] Do you have any insight as to why packages "python34" and "python36" do not apparently do a "%Provides: python3" ? Was there something in Python34 and Python36 that notably altered the language yet again ? [07:47:17] One *possible* solution -- read: unsure yet -- is that for dist = '.el7' that I may get away with a Requires on python34. We *can* install python34 from Fedora's EPEL, and it does install /usr/bin/python3. [07:48:53] pwodkowx, peluse: gerrithub seems to be working for me now [07:50:04] I'm not an expert in python. I think they can be quite old. I remember that python3 on Centos don't provide python3-config-shell [07:50:39] so python2 is only option there. The same might be true for el7 but I'm not sure. [07:51:02] What's the output of "rpm -q --provides python3' on a Fedora system ? [07:52:03] $ rpm -q --provides python3 [07:52:04] python(abi) = 3.6 [07:52:04] python3 = 3.6.6-1.fc28 [07:52:04] python3(x86-64) = 3.6.6-1.fc28 [07:52:04] python36 = 3.6.6-1.fc28 [07:52:05] system-python = 3.6.6-1.fc28 [07:52:06] system-python(abi) = 3.6 [07:52:10] system-python(x86-64) = 3.6.6-1.fc28 [07:52:43] Well, python36 is also available on Fedora's EPEL. I'm going to download it and inspect its contents. [07:53:48] pwodkowx: I have a meeting that starts in 5 minutes, but should be back here in about an hour. Until later... [07:56:14] jimharris, yup, I just got in. [07:56:28] * peluse will be offline for a few hrs.... [08:09:49] jimharris: what licence we want to declare in for our packages? BSD? [08:38:43] https://github.com/spdk/spdk/blob/master/LICENSE [08:38:46] 3 clause BSD [08:41:16] ^ this [09:10:11] bwalker: jimharris: I've never seen a full copyright "clause" in a spec file. Instead, it's just simply something like "BSD" or maybe multi licensed like: "BSD and LGPLv2 and GPLv2". [09:10:18] pwodkowx [09:17:02] i don't think bwalker was suggesting to put the full clause in the spec file - it was just a pointer to spdk's license [09:21:49] Ok, just wanted to be clear. Thx. [09:24:21] lhodev: check the package now, It is should use python3 for f28 and python2 for el7 [09:24:43] jimharris: I think I asked this previously, so forgive me -- not enough coffee -- but we're postponing any merge of 429287 (mk: add framework...) to after 18.10.1, right? [09:25:12] pwodkowx: I'm preparing to do that now. In fact, not only was I inspecting it via Gerrit, but was about to pull it down and do an rpmbuild with it. [09:25:12] also hit other warning now: is there any reason we mark shared libs executable ? [09:25:19] yeah - there's too much other stuff we need to get in place first to really do inter-library dependencies [09:25:55] pwodkowx: The lion's share -- so not 100% -- of shared libs I see installed on my OL system are marked with execute. Don't know why. [09:26:49] pwodkowx: On your Fedora system, do all (most? any?) of the shared libs only have read perms? [09:28:38] The DPDK shared libs also installed with execute set on my system. [09:28:45] hmm... they are executable but this warning [09:28:47] libzzip-0.so.13.0.69 [09:28:54] sorry not that :D [09:29:44] *** WARNING: ./usr/lib64/libspdk.so.1.0 is executable but has empty or no shebang, removing executable bit [09:29:54] is only for libspdk.so* [09:30:24] so there is something magic with this lib I think or I did something wrong [09:30:53] pwodkowx: No, you didn't. The "libspdk.so.1.0" is known as a "implicit linker script". It's not an actual binary shared library. [09:31:37] libc and DPDK use the same kind of mechanism to group the full collection of their respective individual shared libs. [09:32:44] I have to run out for about 15-20 minutes again. Ugh. Sorry. Back shortly. [09:34:45] I don't like warning :( [09:38:40] I wouldn't be opposed to changing the makefile install invocations such that it does 644 for the libs if you want. [09:39:32] I think that would only touch mk/spdk.common.mk in a few places. [09:41:54] I don't know if this is an issue with rpmbuild, know that durig build it inspects text files and removes 'x'. So it see that libspdk.so is text file and remove 'x' + warning [09:42:35] all other *.so are executable and no issue with them. [09:43:06] lhodev: do you think there is anything else to cover? [09:45:51] be back on modnay, bye for now. [09:46:06] later pawel [10:03:11] * peluse didn't do it (the x bit thing) ;) [10:37:18] pwodkowx: I did see that you have departed until Monday so not expecting to hear back from you until then. However, wanted to report that upon attempting to install spdk-tools using latest spec file (patch 21), I got a failure for the requires of 'python-pexpect'. On my distro, the package name is just 'pexpect' -- not 'python-pexpect'. Will change the spec file for my dist and retry. [10:54:42] jimharris, bwalker are there are any more patches for review for 18.10? Feel like something isn't right, my query only shows the crypto reset patch for hashtag 18.10 [10:55:08] that's the only one [10:55:25] wow, cool [10:56:05] and now it's merged [10:56:16] rock-n-roll! [10:56:18] code is frozen (documentation, changelog stuff ok still) [10:56:39] we'll unfreeze as soon as the scans are done on monday or tuesday [10:59:43] *** Joins: travis-ci (~travis-ci@ec2-54-81-39-152.compute-1.amazonaws.com) [10:59:44] (spdk/master) crypto: add proper reset handling (paul luse) [10:59:45] Diff URL: https://github.com/spdk/spdk/compare/40da9ab5e360...7f6738e12d92 [10:59:45] *** Parts: travis-ci (~travis-ci@ec2-54-81-39-152.compute-1.amazonaws.com) () [11:15:58] pwodkowx: Wow -- just wow. I committed a change locally to change the shared lib permissions from 755 to 644, and would you believe that actually breaks the "yum install" ?!? It's crazy. [11:16:10] I see: [11:16:38] Marking spdk-18.10-0.el7.x86_64.rpm to be installed [11:16:46] Marking spdk-18.10-0.el7.x86_64.rpm to be installed [11:17:24] --> Running transaction check [11:17:32] ---> Package spdk.x86_64 0:18.10-0.el7 will be installed [11:17:53] ... [11:17:55] --> Finished Dependency Resolution [11:18:03] Error: Package: spdk-18.10-0.el7.x86_64 (/spdk-18.10-0.el7.x86_64) [11:18:11] Requires: libspdk_vbdev_raid.so.1()(64bit) [11:18:26] And errors for all of the subsequent shared libs. [11:18:35] All because I eliminated the +x bit. [11:19:01] Note that the actual complaint appears to be about the missing symlink that *subsequently* gets created via ldconfig. [11:19:36] But, for who-knows-why reasons, this all craps out because the shared libs don't have the +x bit set. [11:20:01] I rebuilt/reinstalled all just to make sure I hadn't done something wrong. [11:21:03] I removed my patch changing the permissions and rebuilt all, and voila it works again. So, for bizarre reason, it actually appears that on my distro I *do* need the +x bit set on the shared libs. [13:46:23] *** Joins: travis-ci (~travis-ci@ec2-54-226-216-168.compute-1.amazonaws.com) [13:46:25] (spdk/master) doc: update doc with instructions for building shared lib (Piotr Pelplinski) [13:46:25] Diff URL: https://github.com/spdk/spdk/compare/7f6738e12d92...9f9cfdc5917e [13:46:25] *** Parts: travis-ci (~travis-ci@ec2-54-226-216-168.compute-1.amazonaws.com) () [13:46:51] if anyone has any documentation patches that they'd like reviewed, we're still willing to merge those [15:50:42] not urgent or anything but this patch removes a extra make of the intel-ipsec for everyone, https://review.gerrithub.io/#/c/spdk/spdk/+/429519/ and is failing because I missed updating the following "lib/env_dpdk/env.mk:DPDK_LIB += $(SPDK_ROOT_DIR)/intel-ipsec-mb/libIPSec_MB.a" Since we moved to the latst ipsec lib and require 'make install' when I remove the "extra" make the lib is no longer in this location, its in the location installed by the ipsec-lib [15:50:42] make itself. Any suggestions on how to code this correctly in the env.mk file would be great :) [16:01:43] (by correctly I mean how to identify the location of the .a file as installed by the ipsec makefile and get that into DPDK_LIB instead of the location where we're building it a second time. BTW, the reason we have to use the ipsec install is because of some dependencies that the DPDK driver (aesni) has on it. So right now we're sorta half-ass doing it both ways [16:03:31] check out lib/env_dpdk/env.mk [16:05:19] well, yeah that's where I need to make the change. I'm not sure how to point it to the location that the ipsec lib make does the isntall of the .a file [16:11:50] it can wait til Mon... I'll mess around with it a bit this weekend. thanks jimharris [16:14:36] can you just try add -lIPSec_MB? [16:15:10] will do [16:16:57] have all of the test pool system had 'make install' run on them for the ipsec library? [16:19:54] yes, Seth ran pkgdep on them after it was updated, same goes for Jekins systems [16:20:30] for whatever reason it doesn't fail for me locally though. I just pushed a change to add the lib to the linker options, see if that works. Thanks for the suggestion [16:20:45] * peluse has to run.... [18:22:13] jimharris, looks like the patch passed w/your suggestion. Pls take a look on Mon, thanks!! [18:22:46] https://review.gerrithub.io/#/c/spdk/spdk/+/429519/ [23:33:43] *** Quits: drv (daniel@oak.drv.nu) (Remote host closed the connection) [23:34:52] *** Joins: drv (daniel@oak.drv.nu) [23:34:53] *** ChanServ sets mode: +o drv