On Thu, Jun 20, 2019 at 03:42:06PM +0530, Deepshikha Khandelwal wrote: > On Thu, Jun 20, 2019 at 3:20 PM Niels de Vos <ndevos@xxxxxxxxxx> wrote: > > > On Thu, Jun 20, 2019 at 02:56:51PM +0530, Amar Tumballi Suryanarayan wrote: > > > On Thu, Jun 20, 2019 at 2:35 PM Niels de Vos <ndevos@xxxxxxxxxx> wrote: > > > > > > > On Thu, Jun 20, 2019 at 02:11:21PM +0530, Amar Tumballi Suryanarayan > > wrote: > > > > > On Thu, Jun 20, 2019 at 1:13 PM Niels de Vos <ndevos@xxxxxxxxxx> > > wrote: > > > > > > > > > > > On Thu, Jun 20, 2019 at 11:36:46AM +0530, Amar Tumballi > > Suryanarayan > > > > wrote: > > > > > > > Considering python3 is anyways the future, I vote for taking the > > > > patch we > > > > > > > did in master for fixing regression tests with python3 into the > > > > release-6 > > > > > > > and release-5 branch and getting over this deadlock. > > > > > > > > > > > > > > Patch in discussion here is > > > > > > > https://review.gluster.org/#/c/glusterfs/+/22829/ and if anyone > > > > > > notices, it > > > > > > > changes only the files inside 'tests/' directory, which is not > > > > packaged > > > > > > in > > > > > > > a release anyways. > > > > > > > > > > > > > > Hari, can we get the backport of this patch to both the release > > > > branches? > > > > > > > > > > > > When going this route, you still need to make sure that the > > > > > > python3-devel package is available on the CentOS-7 builders. And I > > > > > > don't know if installing that package is already sufficient, maybe > > the > > > > > > backport is not even needed in that case. > > > > > > > > > > > > > > > > > I was thinking, having this patch makes it compatible with both > > python2 > > > > and > > > > > python3, so technically, it allows us to move to Fedora30 if we need > > to > > > > run > > > > > regression there. (and CentOS7 with only python2). > > > > > > > > > > The above patch made it compatible, not mandatory to have python3. > > So, > > > > > treating it as a bug fix. > > > > > > > > Well, whatever Python is detected (python3 has preference over > > python2), > > > > needs to have the -devel package available too. Detection is done by > > > > probing the python<X> executable. The Matching header files from -devel > > > > need to be present in order to be able to build glupy (and others?). > > > > > > > > I do not think compatibility for python3/2 is the problem while > > > > building the tarball. > > > > > > > > > Got it! True. Compatibility is not the problem to build the tarball. > > > > > > I noticed the issue of smoke is coming only from strfmt-errors job, which > > > checks for 'epel-6-i386' mock, and fails right now. > > > > > > The backport might become relevant while running > > > > tests on environments where there is no python2. > > > > > > > > > > > Backport is very important if we are running in a system where we have > > only > > > python3. Hence my proposal to include it in releases. > > > > I am sure CentOS-7 still has python2. The newer python3 only gets pulled > > in by some additional packages that get installed from EPEL. > > > > > But we are stuck with strfmt-errors job right now, and looking at what it > > > was intended to catch in first place, mostly our > > > https://build.gluster.org/job/32-bit-build-smoke/ would be doing same. > > If > > > that is the case, we can remove the job altogether. Also note, this job > > is > > > known to fail many smokes with 'Build root is locked by another process' > > > errors. > > > > This error means that there are multiple concurrent jobs running 'mock' > > with this buildroot. That should not happen and is a configuration error > > in one or more Jenkins jobs. > > Adding to this, this error occurs when the last running job using mock has > been aborted and no proper cleaning/killing in the build root has happened. > I'm planning to call up a cleanup function on abort. Ah, right, that is a possibility too. Jobs should cleanup after themselves and if that is not happening, it is a bug in the job (or missing cleanup on boot). > > > Would be great if disabling strfmt-errors is an option. > > > > I think both jobs do different things. The smoke is functional, where as > > strfmt-errors catches incorrect string formatting (some maintainers > > assume always 64-bit, everywhere) that has been missed in reviews. > > > Is there any specific reason to use 64-bit for strfmt-errors? No, we still support several 32-bit architectures. > Also I have a doubt here, if it needs python3-devel package to build glupy > it should have failed for basic smoke testing where we do source build > install? I do not know if smoke enables/disables building of glupy. Niels _______________________________________________ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/836554017 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/486278655 Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-devel
