[01:43:23] *** Joins: pniedzwx_ (~pniedzwx_@89-77-161-93.dynamic.chello.pl) [01:45:13] *** Quits: wzh (~wzh@114.255.44.139) (Ping timeout: 246 seconds) [01:48:42] *** Quits: pniedzwx_ (~pniedzwx_@89-77-161-93.dynamic.chello.pl) (Ping timeout: 250 seconds) [03:32:58] *** Joins: amit1234 (c0374fa5@gateway/web/freenode/ip.192.55.79.165) [04:45:23] *** Quits: amit1234 (c0374fa5@gateway/web/freenode/ip.192.55.79.165) (Ping timeout: 256 seconds) [07:46:29] *** Joins: tomzawadzki (uid327004@gateway/web/irccloud.com/x-zeivqgbhwybyobvc) [07:58:38] *** Joins: travis-ci (~travis-ci@ec2-54-163-1-198.compute-1.amazonaws.com) [07:58:39] (spdk/v18.10.x) fio_plugin: Perform initialization and teardown on consistent thread (Ben Walker) [07:58:39] Diff URL: https://github.com/spdk/spdk/compare/8c3856bb6bb6...ffa07029b11c [07:58:39] *** Parts: travis-ci (~travis-ci@ec2-54-163-1-198.compute-1.amazonaws.com) () [08:39:52] *** Joins: travis-ci (~travis-ci@ec2-54-91-15-130.compute-1.amazonaws.com) [08:39:53] (spdk/master) util: added bit array bitmask load, store and clear (Wojciech Malikowski) [08:39:54] Diff URL: https://github.com/spdk/spdk/compare/7245134ab0bb...212eb89376a6 [08:39:54] *** Parts: travis-ci (~travis-ci@ec2-54-91-15-130.compute-1.amazonaws.com) () [08:42:58] sethhowe: i posted a couple of small comments on your holiday patch :) [08:48:31] looking at xiaodong's patch for spdk_env_post_init() [08:48:50] i'm wondering if we should have an include/spdk/env_dpdk.h? [08:49:15] i'm just thinking about how to try to describe spdk_env_post_init() for some non-DPDK implementation of the env layer [08:49:47] i think it's easier to just say "if you're using DPDK, and you've already called rte_eal_init, just include env_dpdk.h and call spdk_env_dpdk_post_init()" [09:00:44] jimharris: Done. Thanks. [09:05:23] LOL, "the holiday patch" [09:20:10] *** Joins: travis-ci (~travis-ci@ec2-54-162-252-153.compute-1.amazonaws.com) [09:20:11] (spdk/master) nvmf/rdma: Fix refcnt check on RDMA QP destroy (Evgeniy Kochetov) [09:20:11] Diff URL: https://github.com/spdk/spdk/compare/212eb89376a6...7da9f8faba87 [09:20:11] *** Parts: travis-ci (~travis-ci@ec2-54-162-252-153.compute-1.amazonaws.com) () [09:20:45] *** Joins: travis-ci (~travis-ci@ec2-54-196-226-99.compute-1.amazonaws.com) [09:20:46] (spdk/master) nvmf: Improve error handling in spdk_nvmf_transport_poll_group_create (Evgeniy Kochetov) [09:20:46] Diff URL: https://github.com/spdk/spdk/compare/7da9f8faba87...d722a1742db7 [09:20:46] *** Parts: travis-ci (~travis-ci@ec2-54-196-226-99.compute-1.amazonaws.com) () [09:57:53] *** Joins: pawelkax (~pawelkax@134.134.139.72) [10:01:32] peluse, benwalker: Could you look at my email? I cannot do review on spdk.intel.com/gerrit [10:08:20] jimharris: With respect to the alignment of the version in the spec file, did you change your mind? [10:08:47] I saw in Tomek's latest updates the elimination of 18.10.1.pre in favor of 18.10.x. [10:09:41] pwodkowx, looking... [10:10:16] actually bwalker just replied [10:10:26] bwalker: can you look at the CTP failure on https://review.gerrithub.io/#/c/spdk/spdk/+/437348/ [10:12:22] I'm going to run that one again just for stats. But I think this patch makes us correctly clean up something, which is exposing other bugs (that we have resolved on master) [10:12:44] I'll keep looking at it and come up with a plan [10:13:50] cool thanks [10:14:54] lhodev: tomzawadzki and i were chatting about this just now - i think we can keep this simpler if we just generally use "18.10.x" for non-tagged commits on that branch rather than trying to pick something with 1.pre, 2.pre, etc. in the name [10:15:18] 1.pre is a bit more descriptive, but even that doesn't tell you exactly which commit it was based off of [10:15:40] the most important part is that we get it right for the commit that gets tagged for v18.10.1 [10:17:15] github also appears to somewhat randomly modify the prefix in the .tar.gz file - it strips the "v" (and we can't figure out how to modify that behavior), so using 18.10.x here helps with that [10:18:05] Doing this then eliminates the need for us to introduce a macro for the name in the %autosetup invocation too. [10:19:04] While that was do-able -- and I verified its operation -- it just adds more complexity and hence opportunity for things to get overlooked when cutting a new release. [10:23:20] so you're on board with version=18.10.x? [10:26:57] I think so. Like master, there just has to be the understanding that if one were to grab the tarball off GitHub for a non-official release like either of these, then they'll just be getting the tip of that branch at that instance in time. [10:27:11] yep [10:27:16] Leave it up to said user to update the spec file therein if they want to use it to produce their own package. [10:36:03] In other packages with which I've had experience, they've maintained the spec file outside of the repo for the source and hence had much more flexibility to alter the version at will. That's of course a double-edged sword and has its own set of headaches. It's why we have a dedicated build team to manage it ;-) [11:04:13] *** Joins: travis-ci (~travis-ci@ec2-54-163-1-198.compute-1.amazonaws.com) [11:04:14] (spdk/v18.10.x) memory: return first translation from mem_map_translate (Seth Howell) [11:04:14] Diff URL: https://github.com/spdk/spdk/compare/ffa07029b11c...34d47ecc350e [11:04:14] *** Parts: travis-ci (~travis-ci@ec2-54-163-1-198.compute-1.amazonaws.com) () [11:34:03] * peluse is gone for the day.... [11:42:41] If one clicks on the Rebase button in the GerritHub GUI as opposed to pulling and rebasing in your own sandbox and re-pushing from there, does Gerrit then retain previous votes rather than nulling them out? [11:44:58] the previous votes are retained if the diff is determined to not have actually changed [11:45:06] doesn't matter which way you do the rebase [11:49:55] Hmmm. I guess in virtually all, if not all, of my rebases, I've never gotten that lucky. Mine seem to always lose the votes even without merge conflicts. I guess somehow maybe some element of the diff got changed nonetheless, huh? [11:50:35] yeah it is very rare to not lose the votes [11:59:37] *** Joins: travis-ci (~travis-ci@ec2-54-167-95-221.compute-1.amazonaws.com) [11:59:38] (spdk/master) thread: Use TLS to accelerate thread look up (Ben Walker) [11:59:38] Diff URL: https://github.com/spdk/spdk/compare/d722a1742db7...605e530a4e42 [11:59:38] *** Parts: travis-ci (~travis-ci@ec2-54-167-95-221.compute-1.amazonaws.com) () [12:17:16] *** Quits: tomzawadzki (uid327004@gateway/web/irccloud.com/x-zeivqgbhwybyobvc) (Quit: Connection closed for inactivity) [13:29:11] *** Joins: tomzawadzki (uid327004@gateway/web/irccloud.com/x-bslwcnehbovjuzst) [14:34:10] *** Joins: travis-ci (~travis-ci@ec2-54-221-67-142.compute-1.amazonaws.com) [14:34:11] (spdk/master) lib/trace: add 3 RPC method for tpoint_group_mask (Liu Xiaodong) [14:34:11] Diff URL: https://github.com/spdk/spdk/compare/605e530a4e42...ae0aae1532c9 [14:34:11] *** Parts: travis-ci (~travis-ci@ec2-54-221-67-142.compute-1.amazonaws.com) () [14:46:28] jimharris, #542 relates to tests for every patch set, not only nightly. Test is skipped on CTP and JTP. [15:13:07] Noted the appearance of "version: 18.10.2 pre" on the Chandler test pool. Are we actually anticipating the release of an 18.10.2 ? [15:16:48] pawelkax: looking... [15:18:33] pawelkax: indeed you are correct [15:18:55] which i guess is all the more reason that we need to fix this :) [15:28:32] In https://ci.spdk.io/spdk-jenkins/results/autotest-per-patch/builds/17537/archive/nvmf_phy_autotest/build.log, is the issue that some cleanup following a test incurred an error (unable to remove a directory) ? Trying to divine exactly why this was marked as failed. [15:38:19] huh - i've never seen that one before [15:39:42] Looking in the cleanup_linux function in scripts/setup.sh. [15:40:07] I don't see how that particular "file" (errr, um, directory) would have gotten matched and assigned to "files_to_clean". [15:40:43] i'm trying to figure out how this rocksdb shm file was created in the first place [15:41:23] i guess this is on jenkins so this VM could have run the rocksdb test previously [15:41:40] but i don't see where rocksdb opens shm files [15:42:22] Alas, I don't see how: echo /dev/shm/* | egrep '(spdk_tgt|iscsi|vhost|nvmf|rocksdb|bdevtest|bdevperf)_trace|spdk_iscsi_conns' would match and thus select /dev/shm/rocksdb.cp1C as an entity to remove. [15:44:20] ah [15:44:33] because echo /dev/shm/* puts all the entries on one line [15:44:59] Ah, so it matches the nvmf_trace one, too. Ugh. [15:48:57] Perhaps that echo should get changed to something like a 'ls -1'. [15:49:27] was just playing with that - I think the egrep then also needs to add a -Z [15:49:44] or the file iterator needs to be changed - it gets confused by the newlines otherwise [15:49:59] you want to take a crack at a patch for that? [15:51:03] Ok. Even though the output of the 'ls -1' generates newlines, the result assignment to the variable has the strings without newlines. [15:51:41] but doesn't that still have the same problem? [15:51:49] the egrep will match the entire line [15:52:14] No, because the grep happens on each separate line first, only extracting the ones that match. [15:52:15] i was going down the ls route, but without the -1 [15:55:35] hmmm - i replicate this basic directory structure in /tmp, and tried: [15:55:37] ls -1 /tmp/shm/* | egrep '(rocksdb|nvmf)_trace' [15:56:10] it does leave out the rocksdb.cp1C directory, but the two nvmf_trace files i created are on separate lines [15:56:38] But what do you see if you assign that to a variable instead? [15:56:49] myvar=$( ls -1 /tmp/shm/* | egrep '(rocksdb|nvmf)_trace') [15:56:57] echo $myvar [15:58:51] /tmp [15:58:51] % files_to_clean=$(ls -1 /tmp/shm/* | egrep '(rocksdb|nvmf)_trace') [15:58:51] /tmp [15:58:51] % echo $files_to_clean [15:58:52] /tmp/shm/nvmf_trace.1 [15:58:53] /tmp/shm/nvmf_trace.o [15:59:21] Hmmm. I wonder if I have something unique in my bash environment. [15:59:51] For me that echo $files_to_clean [15:59:51] appears as: [15:59:52] or maybe it's because i'm using zsh :). let me try bash [16:00:16] Ah, zsh could very well be the culprit. [16:00:16] works on bash [16:00:19] yep [16:00:26] And there was much rejoicing ;-) [16:00:53] cool - i'm filing a bug for this - do you want me to assign you to it? [16:01:01] Sure. [16:01:32] Shall I commit first to master, and then do a cherry-pick to v18.10.x ? [16:02:01] i don't think we need this on v18.10.x [16:02:31] As long as we can get those darn commits approved in v18.10.x so we can cut 18.10.1 ;-) ;-) ;-) [16:04:01] and i just realized you're not a member of the spdk project on GitHub - you should have an invite incoming [16:04:36] no membership == no issue assignments (and no, this doesn't get you out of pushing the patch!) [16:07:06] (chuckle). I just clicked through the email invite stuff. [16:18:51] lhodev: on the 18.10.2 - this is always first commit after each release that we do, including master. [16:20:10] tomzawadzki: I can understand it for master, but it seems, well, a bit premature IMHO to do on a release branch. It suggest -- well, to me -- that there *is* an impending or otherwise planned release on that branch. [16:24:16] it's really to make sure we don't accidentally merge a patch in the future [16:24:23] that would be against the tagged version number [16:25:18] we *could* wait until just before we identify some patch that's needed, but I like doing it this way as part of the release process [16:27:07] I'd cast my vote for that -- i.e. wait until... -- but if that's your standard release process, then that's cool. [16:31:30] *** Joins: travis-ci (~travis-ci@ec2-54-162-252-153.compute-1.amazonaws.com) [16:31:31] (spdk/master) include/reduce: remove declaration of non-existent function (wuzhouhui) [16:31:31] Diff URL: https://github.com/spdk/spdk/compare/ae0aae1532c9...c14dd64467fd [16:31:31] *** Parts: travis-ci (~travis-ci@ec2-54-162-252-153.compute-1.amazonaws.com) () [17:04:10] Is this another "failure" type during cleanup? https://ci.spdk.io/spdk/builds/review/66fff3d99a35f383f3a7973997672a896f0a1e53.1544826616/fedora-03/build.log [17:04:51] Is this failing in cleanup because 'modprobe -r uio_pci_generic" returned non-zero ? [17:37:45] Bewildered why Jenkins CI is showing some jobs incomplete -- still running well past the amount of time expected. Anyone know what's going on with that? [19:07:16] *** Quits: tomzawadzki (uid327004@gateway/web/irccloud.com/x-bslwcnehbovjuzst) (Quit: Connection closed for inactivity)