[08:09:14] Good mornin' folks. Can someone please share with me the version of gcc employed on the fedora build pool systems? I tried snooping through some of the build.log's of recent builds, but didn't note that (though I could've sworn I've seen that printed in there in the past). [08:10:02] @klateck [08:11:15] lhodev: which machine in particular do you need? [08:13:10] darsto: It appears that all the fedora-XX systems are running the same OS version so I assumed that they likely would all have the same version of gcc. Is that a bad assumption? [08:14:26] I have no idea about that [08:14:36] I've never hit any gcc-specific bugs [08:16:31] *** Joins: tomzawadzki (tomzawadzk@nat/intel/x-tmwqtyzhdgihkuzz) [08:19:47] quti [08:20:14] darsto: I've run into an issue on a system (local to me) when I configure the SPDK with "—enable-coverage". Following a build, when I attempt to run SPDK's unittest.sh, I'm seeing some complaints about badly formatted ("unexpected EOF") gcno files. I google'd this and found some incidents where, at least anecdotally, opinions were expressed that this was due to a gcc bug. And, more specifically, others experiencing this were runnin [08:20:14] g a version of gcc similar to mine (4.8.5-xxx). I noted at least one person who said when they updated to gcc (4.9-x) that the problem went away. [08:23:44] gcc 4.x? I believe that's unsupported [08:25:56] *confused* gcc 4.x unsupported? As in unsupported on the versions of the Fedora systems in our build pool? [08:26:14] What version are they running then? [08:26:54] unsupported by the gcc community, I mean* [08:28:46] tomzawadzki: could you check? [08:28:51] I don't have access to TP [08:31:23] darsto: Hmmm. I'm on an Oracle Linux 7 distro, and the gcc version thereon is 4.8.5. When I've attempted an update, that's the latest version, or so it appears, that's available unless, I guess, I get creative and try to grab a version elsewhere, satisfy those dependencies, etc. [08:33:39] lhodev: https://gcc.gnu.org/ml/gcc/2015-06/msg00215.html [08:33:51] gcc 4.8.x is not maintained anymore [08:34:21] lhodev: are you just looking for confirmation that the test pool is not running gcc 4.8.x? [08:36:51] Jim: No, it's not that I'm seeking confirmation that the TP is NOT running any gcc 4.8.x — at least that wasn't my 1st thought — but moreover just to learn what version they are running. If I'm going to see if I can get another version of gcc and related pkg's to operate on my system, I'd like to learn of one to target which might increase my optimism of a solution for the bad gcno files. [08:37:05] we should probably print gcc version in autotest [08:37:18] darsto: +2 +2 +2 ;-) [08:37:37] i'm doing that patch right now [08:37:47] will put it in autobuild.sh actually [08:38:21] Jim: If not done already, could you also output the version of lcov? [08:40:12] thanks jim, i'm in a middle of rebase now [09:00:21] drv: does this look right? https://review.gerrithub.io/#/c/399431/ [09:01:30] jimharris: looks right to me, but I haven't had my coffee yet :) [09:05:57] *** Quits: tomzawadzki (tomzawadzk@nat/intel/x-tmwqtyzhdgihkuzz) (Ping timeout: 240 seconds) [09:09:28] lhodev, darsto: series of three patches adding CC, CXX and lcov version information starts at https://review.gerrithub.io/#/c/399431/ [09:34:23] hmm, what's going on with all of these fedora-07 failures? is your series not rebased on latest master? [09:36:13] verify: bad magic header 0, wanted acca at file VirtioScsi3t0 offset 68100096, length 4096 [09:36:35] not rebased, VirtioScsi3t0 is what we removed last friday [09:36:40] yeah, it is just not rebased on the patch that disables the virtio-scsi-pci test [09:36:50] no new problems, just the existing problem :) [09:37:10] perfect. [09:45:05] can we have softroce installed on fedora-05 and fedora-08 [09:45:07] ? [09:51:52] I think we should already have the rxe tools installed on all the Fedora test machines (right, sethhowe?) [10:10:45] Yes. That is the case. [10:49:25] *** Quits: AlanA (9457170b@gateway/web/freenode/ip.148.87.23.11) (Quit: Page closed) [13:20:26] drv: https://review.gerrithub.io/#/c/397113/ adds at least 35 seconds to the test pool time per patch [13:22:35] hmm, that is not great... [13:22:47] it's only running on fedora-07, which is already one of the longest machines [13:23:01] wait, sorry, it seems to be on fedora-08 [13:23:33] could we move SPDK_TEST_LVOL from fedora-08 to fedora-01? [13:24:16] did we ever check in sethhowe's patch that generates a file showing which tests run on which machines? [13:28:35] i don't think so [13:28:39] can you take a look at https://review.gerrithub.io/#/c/399432/ again? [13:37:13] lgtm [14:02:41] *** Quits: ChanServ (ChanServ@services.) (shutting down) [14:10:40] *** Joins: ChanServ (ChanServ@services.) [14:10:40] *** wolfe.freenode.net sets mode: +o ChanServ [14:42:41] drv: in lvol.sh, test case #700 is the one that takes the longest (by far) - if we reduce the size of each created logical volume from 10% of the size of the namespace to 2%, we cut 24 seconds off the test time [14:42:53] sounds good to me [14:43:01] why does it take so long? just from zeroing out the space? [14:44:28] yes [16:06:21] hi pzedlews [16:08:01] hi! I'm back, finally! Had issues with my memory ;). Today, finally, my 100th secret password worked [16:09:18] was it "password100"? [16:09:25] wow, I wish the systems I try to log into would give me 100 tries :) [16:09:36] I'll bet it was 123456 [16:10:09] I've got the same combination on my luggage! ;) [16:10:26] drv: sth like that. I'm kidding of course, but anyway, was tired of it for some time [16:24:34] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [21:58:29] *** Quits: drv (daniel@oak.drv.nu) (Remote host closed the connection) [22:04:10] *** Joins: drv (daniel@oak.drv.nu) [22:04:10] *** ChanServ sets mode: +o drv [22:31:18] *** Quits: drv (daniel@oak.drv.nu) (Ping timeout: 240 seconds)