On Thu, Jun 20, 2019 at 3:20 PM Niels de Vos <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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. > > 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? 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? > > Niels > > > > > > Regards, > > > > > Niels > > > > > > > > > > > > > > > > > > > Niels > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > Amar > > > > > > > > > > > > On Thu, Jun 13, 2019 at 7:26 PM Michael Scherer < > [email protected] > > > > > > > > > wrote: > > > > > > > > > > > > > Le jeudi 13 juin 2019 à 14:28 +0200, Niels de Vos a écrit : > > > > > > > > On Thu, Jun 13, 2019 at 11:08:25AM +0200, Niels de Vos wrote: > > > > > > > > > On Wed, Jun 12, 2019 at 04:09:55PM -0700, Kaleb Keithley > wrote: > > > > > > > > > > On Wed, Jun 12, 2019 at 11:36 AM Kaleb Keithley < > > > > > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi > > > Suryanarayan < > > > > > > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We recently noticed that in one of the package > update on > > > > > > > > > > > > builder (ie, > > > > > > > > > > > > centos7.x machines), python3.6 got installed as a > > > dependency. > > > > > > > > > > > > So, yes, it > > > > > > > > > > > > is possible to have python3 in centos7 now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > EPEL updated from python34 to python36 recently, but C7 > > > doesn't > > > > > > > > > > > have > > > > > > > > > > > python3 in the base. I don't think we've ever used EPEL > > > > > > > > > > > packages for > > > > > > > > > > > building. > > > > > > > > > > > > > > > > > > > > > > And GlusterFS-5 isn't python3 ready. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Correction: GlusterFS-5 is mostly or completely python3 > > > > > > > > > > ready. FWIW, > > > > > > > > > > python33 is available on both RHEL7 and CentOS7 from the > > > Software > > > > > > > > > > Collection Library (SCL), and python34 and now python36 > are > > > > > > > > > > available from > > > > > > > > > > EPEL. > > > > > > > > > > > > > > > > > > > > But packages built for the CentOS Storage SIG have never > > > used the > > > > > > > > > > SCL or > > > > > > > > > > EPEL (EPEL not allowed) and the shebangs in the .py > files are > > > > > > > > > > converted > > > > > > > > > > from /usr/bin/python3 to /usr/bin/python2 during the > rpmbuild > > > > > > > > > > %prep stage. > > > > > > > > > > All the python dependencies for the packages remain the > > > python2 > > > > > > > > > > flavors. > > > > > > > > > > AFAIK the centos-regression machines ought to be > building the > > > > > > > > > > same way. > > > > > > > > > > > > > > > > > > Indeed, there should not be a requirement on having EPEL > > > enabled on > > > > > > > > > the > > > > > > > > > CentOS-7 builders. At least not for the building of the > > > glusterfs > > > > > > > > > tarball. We still need to do releases of glusterfs-4.1 and > > > > > > > > > glusterfs-5, > > > > > > > > > until then it is expected to have python2 as the (only?) > > > version > > > > > > > > > for the > > > > > > > > > system. Is it possible to remove python3 from the CentOS-7 > > > builders > > > > > > > > > and > > > > > > > > > run the jobs that require python3 on the Fedora builders > > > instead? > > > > > > > > > > > > > > > > Actually, if the python-devel package for python3 is > installed > > > on the > > > > > > > > CentOS-7 builders, things may work too. It still feels like > some > > > sort > > > > > > > > of > > > > > > > > Frankenstein deployment, and we don't expect to this see in > > > > > > > > production > > > > > > > > environments. But maybe this is a workaround in case > something > > > > > > > > really, > > > > > > > > really, REALLY depends on python3 on the builders. > > > > > > > > > > > > > > To be honest, people would be surprised what happen in > production > > > > > > > around (sysadmins tend to discuss around, we all have horrors > > > stories, > > > > > > > stuff that were supposed to be cleaned and wasn't, etc) > > > > > > > > > > > > > > After all, "frankenstein deployment now" is better than > "perfect > > > > > > > later", especially since lots of IT departements are under > constant > > > > > > > pressure (so that's more "perfect never"). > > > > > > > > > > > > > > I can understand that we want clean and simple code (who > doesn't), > > > but > > > > > > > real life is much messier than we want to admit, so we need > > > something > > > > > > > robust. > > > > > > > > > > > > > > -- > > > > > > > Michael Scherer > > > > > > > Sysadmin, Community Infrastructure > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > 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 > > > > > > > [email protected] > > > > > > > https://lists.gluster.org/mailman/listinfo/gluster-devel > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Amar Tumballi (amarts) > > > > > > > > > > > > > > > > > -- > > > > Amar Tumballi (amarts) > > > > > > > > > -- > > Amar Tumballi (amarts) > _______________________________________________ > > 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 > [email protected] > https://lists.gluster.org/mailman/listinfo/gluster-devel > >
_______________________________________________ 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 [email protected] https://lists.gluster.org/mailman/listinfo/gluster-devel
