Re: [Gluster-devel] Removing glupy from release 5.7
I'll make the changes for prioritizing python2 over 3 for release 5 and 4. Let me know if we need to make any other changes. Thanks! On Mon, Jul 8, 2019 at 3:07 PM Niels de Vos wrote: > > On Mon, Jul 08, 2019 at 02:37:34PM +0530, Hari Gowtham wrote: > > I have a few concerns about adding the python3 devel package and > > continuing the build. > > In the effort to make Gluster python3 compatible, > > https://github.com/gluster/glusterfs/issues/411 > > I think we have decided to skip working on Glupy to make it python3 > > compatible. > > (Correct me if i'm wrong.) As Glupy was decided to be deprecated. > > Though i don't see any mail thread regarding the same. > > I don't see any patches merged to make Glupy python3 compatible, as well. > > > > In such a case, I think its better to make changes to the configure.ac > > of release 5 to work with python2 alone. > > This way, Glupy will not be affected as well. And machines with > > python3 will also work because of the presence of python2. > > And no change will be needed on the infra side as well. > > Building when only python3 is available should still keep working as > well. Recent Fedora versions do not have python2 (by default?) anymore, > and that may be true for other distributions too. > > configure.ac for release-5 and release-4.1 should probably prefer > python2 before python3. > > Niels > > > > We are a bit too late with the 5 series releases. If we are fine with > > this approach, > > I will send out a mail informing this, work on the patch and push it. > > > > > > On Fri, Jul 5, 2019 at 6:48 PM Niels de Vos wrote: > > > > > > On Thu, Jul 04, 2019 at 05:03:53PM +0200, Michael Scherer wrote: > > > > Le jeudi 04 juillet 2019 à 16:20 +0200, Niels de Vos a écrit : > > > > > On Wed, Jul 03, 2019 at 04:46:11PM +0200, Michael Scherer wrote: > > > > > > Le mercredi 03 juillet 2019 à 20:03 +0530, Deepshikha Khandelwal a > > > > > > écrit : > > > > > > > Misc, is EPEL got recently installed on the builders? > > > > > > > > > > > > No, it has been there since september 2016. What got changed is > > > > > > that > > > > > > python3 wasn't installed before. > > > > > > > > > > > > > Can you please resolve the 'Why EPEL on builders?'. EPEL+python3 > > > > > > > on > > > > > > > builders seems not a good option to have. > > > > > > > > > > > > > > > > > > Python 3 is pulled by 'mock', cf > > > > > > > > > > https://lists.gluster.org/pipermail/gluster-devel/2019-June/056347.html > > > > > > > > > > > > So sure, I can remove EPEL, but then it will remove mock. Or I can > > > > > > remove python3, and it will remove mock. > > > > > > > > > > > > But again, the problem is not with the set of installed packages on > > > > > > the > > > > > > builder, that's just showing there is a bug. > > > > > > > > > > > > The configure script do pick the latest python version: > > > > > > https://github.com/gluster/glusterfs/blob/master/configure.ac#L612 > > > > > > > > > > > > if there is a python3, it take that, if not, it fall back to > > > > > > python2. > > > > > > > > > > > > then, later: > > > > > > https://github.com/gluster/glusterfs/blob/master/configure.ac#L639 > > > > > > > > > > > > it verify the presence of what is required to build. > > > > > > > > > > > > So if there is a runtime version only of python3, it will detect > > > > > > python3, but not build anything, because the -devel subpackage is > > > > > > not h > > > > > > ere. > > > > > > > > > > > > There is 2 solutions: > > > > > > - fix that piece of code, so it doesn't just test the presence of > > > > > > python executable, but do that, and test the presence of headers > > > > > > before > > > > > > deciding if we need to build or not glupy. > > > > > > > > > > > > - use PYTHON env var to force python2, and document that it need to > > > > > > be > > > > > > done. > > > > > > > > > > What about option 3: > > > > > > > > > > - install python3-devel in addition to python3 > > > > > > > > That's a option, but I think that's a disservice for the users, since > > > > that's fixing our CI to no longer trigger a corner case, which doesn't > > > > mean the corner case no longer exist, just that we do not trigger it. > > > > > > This is only interesting for building releases/packages, I think. Normal > > > build environments have -devel packages installed for the components > > > that are used during the build process. The weird python2-devel and > > > python3 (without -devel) is definitely a corner case, but not something > > > people would normally have. And if so, we expect -devel for the python > > > version that is used, so developers would hopefully just install that on > > > their build system. > > > > > > 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 >
Re: [Gluster-devel] Removing glupy from release 5.7
On Mon, Jul 08, 2019 at 02:37:34PM +0530, Hari Gowtham wrote: > I have a few concerns about adding the python3 devel package and > continuing the build. > In the effort to make Gluster python3 compatible, > https://github.com/gluster/glusterfs/issues/411 > I think we have decided to skip working on Glupy to make it python3 > compatible. > (Correct me if i'm wrong.) As Glupy was decided to be deprecated. > Though i don't see any mail thread regarding the same. > I don't see any patches merged to make Glupy python3 compatible, as well. > > In such a case, I think its better to make changes to the configure.ac > of release 5 to work with python2 alone. > This way, Glupy will not be affected as well. And machines with > python3 will also work because of the presence of python2. > And no change will be needed on the infra side as well. Building when only python3 is available should still keep working as well. Recent Fedora versions do not have python2 (by default?) anymore, and that may be true for other distributions too. configure.ac for release-5 and release-4.1 should probably prefer python2 before python3. Niels > We are a bit too late with the 5 series releases. If we are fine with > this approach, > I will send out a mail informing this, work on the patch and push it. > > > On Fri, Jul 5, 2019 at 6:48 PM Niels de Vos wrote: > > > > On Thu, Jul 04, 2019 at 05:03:53PM +0200, Michael Scherer wrote: > > > Le jeudi 04 juillet 2019 à 16:20 +0200, Niels de Vos a écrit : > > > > On Wed, Jul 03, 2019 at 04:46:11PM +0200, Michael Scherer wrote: > > > > > Le mercredi 03 juillet 2019 à 20:03 +0530, Deepshikha Khandelwal a > > > > > écrit : > > > > > > Misc, is EPEL got recently installed on the builders? > > > > > > > > > > No, it has been there since september 2016. What got changed is > > > > > that > > > > > python3 wasn't installed before. > > > > > > > > > > > Can you please resolve the 'Why EPEL on builders?'. EPEL+python3 > > > > > > on > > > > > > builders seems not a good option to have. > > > > > > > > > > > > > > > Python 3 is pulled by 'mock', cf > > > > > > > > https://lists.gluster.org/pipermail/gluster-devel/2019-June/056347.html > > > > > > > > > > So sure, I can remove EPEL, but then it will remove mock. Or I can > > > > > remove python3, and it will remove mock. > > > > > > > > > > But again, the problem is not with the set of installed packages on > > > > > the > > > > > builder, that's just showing there is a bug. > > > > > > > > > > The configure script do pick the latest python version: > > > > > https://github.com/gluster/glusterfs/blob/master/configure.ac#L612 > > > > > > > > > > if there is a python3, it take that, if not, it fall back to > > > > > python2. > > > > > > > > > > then, later: > > > > > https://github.com/gluster/glusterfs/blob/master/configure.ac#L639 > > > > > > > > > > it verify the presence of what is required to build. > > > > > > > > > > So if there is a runtime version only of python3, it will detect > > > > > python3, but not build anything, because the -devel subpackage is > > > > > not h > > > > > ere. > > > > > > > > > > There is 2 solutions: > > > > > - fix that piece of code, so it doesn't just test the presence of > > > > > python executable, but do that, and test the presence of headers > > > > > before > > > > > deciding if we need to build or not glupy. > > > > > > > > > > - use PYTHON env var to force python2, and document that it need to > > > > > be > > > > > done. > > > > > > > > What about option 3: > > > > > > > > - install python3-devel in addition to python3 > > > > > > That's a option, but I think that's a disservice for the users, since > > > that's fixing our CI to no longer trigger a corner case, which doesn't > > > mean the corner case no longer exist, just that we do not trigger it. > > > > This is only interesting for building releases/packages, I think. Normal > > build environments have -devel packages installed for the components > > that are used during the build process. The weird python2-devel and > > python3 (without -devel) is definitely a corner case, but not something > > people would normally have. And if so, we expect -devel for the python > > version that is used, so developers would hopefully just install that on > > their build system. > > > > 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@gluster.org > > https://lists.gluster.org/mailman/listinfo/gluster-devel > > > > > -- > Regards, > Hari Gowtham. ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/836554017 NA/EMEA Schedule - Ev
Re: [Gluster-devel] Removing glupy from release 5.7
I have a few concerns about adding the python3 devel package and continuing the build. In the effort to make Gluster python3 compatible, https://github.com/gluster/glusterfs/issues/411 I think we have decided to skip working on Glupy to make it python3 compatible. (Correct me if i'm wrong.) As Glupy was decided to be deprecated. Though i don't see any mail thread regarding the same. I don't see any patches merged to make Glupy python3 compatible, as well. In such a case, I think its better to make changes to the configure.ac of release 5 to work with python2 alone. This way, Glupy will not be affected as well. And machines with python3 will also work because of the presence of python2. And no change will be needed on the infra side as well. We are a bit too late with the 5 series releases. If we are fine with this approach, I will send out a mail informing this, work on the patch and push it. On Fri, Jul 5, 2019 at 6:48 PM Niels de Vos wrote: > > On Thu, Jul 04, 2019 at 05:03:53PM +0200, Michael Scherer wrote: > > Le jeudi 04 juillet 2019 à 16:20 +0200, Niels de Vos a écrit : > > > On Wed, Jul 03, 2019 at 04:46:11PM +0200, Michael Scherer wrote: > > > > Le mercredi 03 juillet 2019 à 20:03 +0530, Deepshikha Khandelwal a > > > > écrit : > > > > > Misc, is EPEL got recently installed on the builders? > > > > > > > > No, it has been there since september 2016. What got changed is > > > > that > > > > python3 wasn't installed before. > > > > > > > > > Can you please resolve the 'Why EPEL on builders?'. EPEL+python3 > > > > > on > > > > > builders seems not a good option to have. > > > > > > > > > > > > Python 3 is pulled by 'mock', cf > > > > > > https://lists.gluster.org/pipermail/gluster-devel/2019-June/056347.html > > > > > > > > So sure, I can remove EPEL, but then it will remove mock. Or I can > > > > remove python3, and it will remove mock. > > > > > > > > But again, the problem is not with the set of installed packages on > > > > the > > > > builder, that's just showing there is a bug. > > > > > > > > The configure script do pick the latest python version: > > > > https://github.com/gluster/glusterfs/blob/master/configure.ac#L612 > > > > > > > > if there is a python3, it take that, if not, it fall back to > > > > python2. > > > > > > > > then, later: > > > > https://github.com/gluster/glusterfs/blob/master/configure.ac#L639 > > > > > > > > it verify the presence of what is required to build. > > > > > > > > So if there is a runtime version only of python3, it will detect > > > > python3, but not build anything, because the -devel subpackage is > > > > not h > > > > ere. > > > > > > > > There is 2 solutions: > > > > - fix that piece of code, so it doesn't just test the presence of > > > > python executable, but do that, and test the presence of headers > > > > before > > > > deciding if we need to build or not glupy. > > > > > > > > - use PYTHON env var to force python2, and document that it need to > > > > be > > > > done. > > > > > > What about option 3: > > > > > > - install python3-devel in addition to python3 > > > > That's a option, but I think that's a disservice for the users, since > > that's fixing our CI to no longer trigger a corner case, which doesn't > > mean the corner case no longer exist, just that we do not trigger it. > > This is only interesting for building releases/packages, I think. Normal > build environments have -devel packages installed for the components > that are used during the build process. The weird python2-devel and > python3 (without -devel) is definitely a corner case, but not something > people would normally have. And if so, we expect -devel for the python > version that is used, so developers would hopefully just install that on > their build system. > > 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@gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-devel > -- Regards, Hari Gowtham. ___ 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
On Thu, Jul 04, 2019 at 05:03:53PM +0200, Michael Scherer wrote: > Le jeudi 04 juillet 2019 à 16:20 +0200, Niels de Vos a écrit : > > On Wed, Jul 03, 2019 at 04:46:11PM +0200, Michael Scherer wrote: > > > Le mercredi 03 juillet 2019 à 20:03 +0530, Deepshikha Khandelwal a > > > écrit : > > > > Misc, is EPEL got recently installed on the builders? > > > > > > No, it has been there since september 2016. What got changed is > > > that > > > python3 wasn't installed before. > > > > > > > Can you please resolve the 'Why EPEL on builders?'. EPEL+python3 > > > > on > > > > builders seems not a good option to have. > > > > > > > > > Python 3 is pulled by 'mock', cf > > > > https://lists.gluster.org/pipermail/gluster-devel/2019-June/056347.html > > > > > > So sure, I can remove EPEL, but then it will remove mock. Or I can > > > remove python3, and it will remove mock. > > > > > > But again, the problem is not with the set of installed packages on > > > the > > > builder, that's just showing there is a bug. > > > > > > The configure script do pick the latest python version: > > > https://github.com/gluster/glusterfs/blob/master/configure.ac#L612 > > > > > > if there is a python3, it take that, if not, it fall back to > > > python2. > > > > > > then, later: > > > https://github.com/gluster/glusterfs/blob/master/configure.ac#L639 > > > > > > it verify the presence of what is required to build. > > > > > > So if there is a runtime version only of python3, it will detect > > > python3, but not build anything, because the -devel subpackage is > > > not h > > > ere. > > > > > > There is 2 solutions: > > > - fix that piece of code, so it doesn't just test the presence of > > > python executable, but do that, and test the presence of headers > > > before > > > deciding if we need to build or not glupy. > > > > > > - use PYTHON env var to force python2, and document that it need to > > > be > > > done. > > > > What about option 3: > > > > - install python3-devel in addition to python3 > > That's a option, but I think that's a disservice for the users, since > that's fixing our CI to no longer trigger a corner case, which doesn't > mean the corner case no longer exist, just that we do not trigger it. This is only interesting for building releases/packages, I think. Normal build environments have -devel packages installed for the components that are used during the build process. The weird python2-devel and python3 (without -devel) is definitely a corner case, but not something people would normally have. And if so, we expect -devel for the python version that is used, so developers would hopefully just install that on their build system. 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
Le jeudi 04 juillet 2019 à 16:20 +0200, Niels de Vos a écrit : > On Wed, Jul 03, 2019 at 04:46:11PM +0200, Michael Scherer wrote: > > Le mercredi 03 juillet 2019 à 20:03 +0530, Deepshikha Khandelwal a > > écrit : > > > Misc, is EPEL got recently installed on the builders? > > > > No, it has been there since september 2016. What got changed is > > that > > python3 wasn't installed before. > > > > > Can you please resolve the 'Why EPEL on builders?'. EPEL+python3 > > > on > > > builders seems not a good option to have. > > > > > > Python 3 is pulled by 'mock', cf > > https://lists.gluster.org/pipermail/gluster-devel/2019-June/056347.html > > > > So sure, I can remove EPEL, but then it will remove mock. Or I can > > remove python3, and it will remove mock. > > > > But again, the problem is not with the set of installed packages on > > the > > builder, that's just showing there is a bug. > > > > The configure script do pick the latest python version: > > https://github.com/gluster/glusterfs/blob/master/configure.ac#L612 > > > > if there is a python3, it take that, if not, it fall back to > > python2. > > > > then, later: > > https://github.com/gluster/glusterfs/blob/master/configure.ac#L639 > > > > it verify the presence of what is required to build. > > > > So if there is a runtime version only of python3, it will detect > > python3, but not build anything, because the -devel subpackage is > > not h > > ere. > > > > There is 2 solutions: > > - fix that piece of code, so it doesn't just test the presence of > > python executable, but do that, and test the presence of headers > > before > > deciding if we need to build or not glupy. > > > > - use PYTHON env var to force python2, and document that it need to > > be > > done. > > What about option 3: > > - install python3-devel in addition to python3 That's a option, but I think that's a disservice for the users, since that's fixing our CI to no longer trigger a corner case, which doesn't mean the corner case no longer exist, just that we do not trigger it. -- Michael Scherer Sysadmin, Community Infrastructure signature.asc Description: This is a digitally signed message part ___ 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
On Wed, Jul 03, 2019 at 04:46:11PM +0200, Michael Scherer wrote: > Le mercredi 03 juillet 2019 à 20:03 +0530, Deepshikha Khandelwal a > écrit : > > Misc, is EPEL got recently installed on the builders? > > No, it has been there since september 2016. What got changed is that > python3 wasn't installed before. > > > Can you please resolve the 'Why EPEL on builders?'. EPEL+python3 on > > builders seems not a good option to have. > > > Python 3 is pulled by 'mock', cf > https://lists.gluster.org/pipermail/gluster-devel/2019-June/056347.html > > So sure, I can remove EPEL, but then it will remove mock. Or I can > remove python3, and it will remove mock. > > But again, the problem is not with the set of installed packages on the > builder, that's just showing there is a bug. > > The configure script do pick the latest python version: > https://github.com/gluster/glusterfs/blob/master/configure.ac#L612 > > if there is a python3, it take that, if not, it fall back to python2. > > then, later: > https://github.com/gluster/glusterfs/blob/master/configure.ac#L639 > > it verify the presence of what is required to build. > > So if there is a runtime version only of python3, it will detect > python3, but not build anything, because the -devel subpackage is not h > ere. > > There is 2 solutions: > - fix that piece of code, so it doesn't just test the presence of > python executable, but do that, and test the presence of headers before > deciding if we need to build or not glupy. > > - use PYTHON env var to force python2, and document that it need to be > done. What about option 3: - install python3-devel in addition to python3 Niels > > > > On Thu, Jun 20, 2019 at 6:37 PM Michael Scherer > > wrote: > > > > > Le jeudi 20 juin 2019 à 08:38 -0400, Kaleb Keithley a écrit : > > > > On Thu, Jun 20, 2019 at 7:39 AM Michael Scherer < > > > > msche...@redhat.com> > > > > wrote: > > > > > > > > > Le jeudi 20 juin 2019 à 06:57 -0400, Kaleb Keithley a écrit : > > > > > > AFAICT, working fine right up to when EPEL and python3 were > > > > > > installed > > > > > > on > > > > > > the centos builders. If it was my decision, I'd undo that > > > > > > change. > > > > > > > > > > The biggest problem is that mock do pull python3. > > > > > > > > > > > > > > > > > > That's mock on Fedora — to run a build in a centos-i386 chroot. > > > > Fedora > > > > already has python3. I don't see how that can affect what's > > > > running > > > > in the > > > > mock chroot. > > > > > > I am not sure we are talking about the same thing, but mock, the > > > rpm > > > package from EPEL 7, do pull python 3: > > > > > > $ cat /etc/redhat-release; rpm -q --requires mock |grep > > > 'python(abi' > > > Red Hat Enterprise Linux Server release 7.6 (Maipo) > > > python(abi) = 3.6 > > > > > > So we do have python3 installed on the Centos 7 builders (and was > > > after > > > a upgrade), and we are not going to remove it, because we use mock > > > for > > > a lot of stuff. > > > > > > And again, if the configure script is detecting the wrong version > > > of > > > python, the fix is not to remove the version of python for the > > > builders, the fix is to detect the right version of python, or at > > > least, permit to people to bypass the detection. > > > > > > > Is the build inside mock also installing EPEL and python3 > > > > somehow? > > > > Now? If so, why? > > > > > > No, I doubt but then, if we are using a chroot, the package > > > installed > > > on the builders shouldn't matter, since that's a chroot. > > > > > > So I am kinda being lost. > > > > > > > And maybe the solution for centos regressions is to run those in > > > > mock, with a centos-x86_64 chroot. Without EPEL or python3. > > > > > > That would likely requires a big refactor of the setup, since we > > > have > > > to get the data out of specific place, etc. We would also need to > > > reinstall the builders to set partitions in a different way, with a > > > bigger / and/or give more space for /var/lib/mock. > > > > > > I do not see that happening fast, and if my hypothesis of a issue > > > in > > > configure is right, then fixing seems the faster way to avoid the > > > issue. > > > -- > > > 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 > > > Gluster-devel@gluster.org > > > https://lists.gluster.org/mailman/listinfo/gluster-devel > > > > > > > -- > Michael Scherer > Sysadmin, Community Infrastructure > > > > ___ > > Community Meeting Calendar: > > APAC Schedule - > Every 2nd and 4th Tuesday
Re: [Gluster-devel] Removing glupy from release 5.7
Le mercredi 03 juillet 2019 à 20:03 +0530, Deepshikha Khandelwal a écrit : > Misc, is EPEL got recently installed on the builders? No, it has been there since september 2016. What got changed is that python3 wasn't installed before. > Can you please resolve the 'Why EPEL on builders?'. EPEL+python3 on > builders seems not a good option to have. Python 3 is pulled by 'mock', cf https://lists.gluster.org/pipermail/gluster-devel/2019-June/056347.html So sure, I can remove EPEL, but then it will remove mock. Or I can remove python3, and it will remove mock. But again, the problem is not with the set of installed packages on the builder, that's just showing there is a bug. The configure script do pick the latest python version: https://github.com/gluster/glusterfs/blob/master/configure.ac#L612 if there is a python3, it take that, if not, it fall back to python2. then, later: https://github.com/gluster/glusterfs/blob/master/configure.ac#L639 it verify the presence of what is required to build. So if there is a runtime version only of python3, it will detect python3, but not build anything, because the -devel subpackage is not h ere. There is 2 solutions: - fix that piece of code, so it doesn't just test the presence of python executable, but do that, and test the presence of headers before deciding if we need to build or not glupy. - use PYTHON env var to force python2, and document that it need to be done. > On Thu, Jun 20, 2019 at 6:37 PM Michael Scherer > wrote: > > > Le jeudi 20 juin 2019 à 08:38 -0400, Kaleb Keithley a écrit : > > > On Thu, Jun 20, 2019 at 7:39 AM Michael Scherer < > > > msche...@redhat.com> > > > wrote: > > > > > > > Le jeudi 20 juin 2019 à 06:57 -0400, Kaleb Keithley a écrit : > > > > > AFAICT, working fine right up to when EPEL and python3 were > > > > > installed > > > > > on > > > > > the centos builders. If it was my decision, I'd undo that > > > > > change. > > > > > > > > The biggest problem is that mock do pull python3. > > > > > > > > > > > > > > That's mock on Fedora — to run a build in a centos-i386 chroot. > > > Fedora > > > already has python3. I don't see how that can affect what's > > > running > > > in the > > > mock chroot. > > > > I am not sure we are talking about the same thing, but mock, the > > rpm > > package from EPEL 7, do pull python 3: > > > > $ cat /etc/redhat-release; rpm -q --requires mock |grep > > 'python(abi' > > Red Hat Enterprise Linux Server release 7.6 (Maipo) > > python(abi) = 3.6 > > > > So we do have python3 installed on the Centos 7 builders (and was > > after > > a upgrade), and we are not going to remove it, because we use mock > > for > > a lot of stuff. > > > > And again, if the configure script is detecting the wrong version > > of > > python, the fix is not to remove the version of python for the > > builders, the fix is to detect the right version of python, or at > > least, permit to people to bypass the detection. > > > > > Is the build inside mock also installing EPEL and python3 > > > somehow? > > > Now? If so, why? > > > > No, I doubt but then, if we are using a chroot, the package > > installed > > on the builders shouldn't matter, since that's a chroot. > > > > So I am kinda being lost. > > > > > And maybe the solution for centos regressions is to run those in > > > mock, with a centos-x86_64 chroot. Without EPEL or python3. > > > > That would likely requires a big refactor of the setup, since we > > have > > to get the data out of specific place, etc. We would also need to > > reinstall the builders to set partitions in a different way, with a > > bigger / and/or give more space for /var/lib/mock. > > > > I do not see that happening fast, and if my hypothesis of a issue > > in > > configure is right, then fixing seems the faster way to avoid the > > issue. > > -- > > 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 > > Gluster-devel@gluster.org > > https://lists.gluster.org/mailman/listinfo/gluster-devel > > > > -- Michael Scherer Sysadmin, Community Infrastructure signature.asc Description: This is a digitally signed message part ___ 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
Misc, is EPEL got recently installed on the builders? Can you please resolve the 'Why EPEL on builders?'. EPEL+python3 on builders seems not a good option to have. On Thu, Jun 20, 2019 at 6:37 PM Michael Scherer wrote: > Le jeudi 20 juin 2019 à 08:38 -0400, Kaleb Keithley a écrit : > > On Thu, Jun 20, 2019 at 7:39 AM Michael Scherer > > wrote: > > > > > Le jeudi 20 juin 2019 à 06:57 -0400, Kaleb Keithley a écrit : > > > > AFAICT, working fine right up to when EPEL and python3 were > > > > installed > > > > on > > > > the centos builders. If it was my decision, I'd undo that > > > > change. > > > > > > The biggest problem is that mock do pull python3. > > > > > > > > > > That's mock on Fedora — to run a build in a centos-i386 chroot. > > Fedora > > already has python3. I don't see how that can affect what's running > > in the > > mock chroot. > > I am not sure we are talking about the same thing, but mock, the rpm > package from EPEL 7, do pull python 3: > > $ cat /etc/redhat-release; rpm -q --requires mock |grep 'python(abi' > Red Hat Enterprise Linux Server release 7.6 (Maipo) > python(abi) = 3.6 > > So we do have python3 installed on the Centos 7 builders (and was after > a upgrade), and we are not going to remove it, because we use mock for > a lot of stuff. > > And again, if the configure script is detecting the wrong version of > python, the fix is not to remove the version of python for the > builders, the fix is to detect the right version of python, or at > least, permit to people to bypass the detection. > > > Is the build inside mock also installing EPEL and python3 somehow? > > Now? If so, why? > > No, I doubt but then, if we are using a chroot, the package installed > on the builders shouldn't matter, since that's a chroot. > > So I am kinda being lost. > > > And maybe the solution for centos regressions is to run those in > > mock, with a centos-x86_64 chroot. Without EPEL or python3. > > That would likely requires a big refactor of the setup, since we have > to get the data out of specific place, etc. We would also need to > reinstall the builders to set partitions in a different way, with a > bigger / and/or give more space for /var/lib/mock. > > I do not see that happening fast, and if my hypothesis of a issue in > configure is right, then fixing seems the faster way to avoid the > issue. > -- > 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 > Gluster-devel@gluster.org > 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 Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
Le jeudi 20 juin 2019 à 08:38 -0400, Kaleb Keithley a écrit : > On Thu, Jun 20, 2019 at 7:39 AM Michael Scherer > wrote: > > > Le jeudi 20 juin 2019 à 06:57 -0400, Kaleb Keithley a écrit : > > > AFAICT, working fine right up to when EPEL and python3 were > > > installed > > > on > > > the centos builders. If it was my decision, I'd undo that > > > change. > > > > The biggest problem is that mock do pull python3. > > > > > > That's mock on Fedora — to run a build in a centos-i386 chroot. > Fedora > already has python3. I don't see how that can affect what's running > in the > mock chroot. I am not sure we are talking about the same thing, but mock, the rpm package from EPEL 7, do pull python 3: $ cat /etc/redhat-release; rpm -q --requires mock |grep 'python(abi' Red Hat Enterprise Linux Server release 7.6 (Maipo) python(abi) = 3.6 So we do have python3 installed on the Centos 7 builders (and was after a upgrade), and we are not going to remove it, because we use mock for a lot of stuff. And again, if the configure script is detecting the wrong version of python, the fix is not to remove the version of python for the builders, the fix is to detect the right version of python, or at least, permit to people to bypass the detection. > Is the build inside mock also installing EPEL and python3 somehow? > Now? If so, why? No, I doubt but then, if we are using a chroot, the package installed on the builders shouldn't matter, since that's a chroot. So I am kinda being lost. > And maybe the solution for centos regressions is to run those in > mock, with a centos-x86_64 chroot. Without EPEL or python3. That would likely requires a big refactor of the setup, since we have to get the data out of specific place, etc. We would also need to reinstall the builders to set partitions in a different way, with a bigger / and/or give more space for /var/lib/mock. I do not see that happening fast, and if my hypothesis of a issue in configure is right, then fixing seems the faster way to avoid the issue. -- Michael Scherer Sysadmin, Community Infrastructure signature.asc Description: This is a digitally signed message part ___ 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
On Thu, Jun 20, 2019 at 7:39 AM Michael Scherer wrote: > Le jeudi 20 juin 2019 à 06:57 -0400, Kaleb Keithley a écrit : > > AFAICT, working fine right up to when EPEL and python3 were installed > > on > > the centos builders. If it was my decision, I'd undo that change. > > The biggest problem is that mock do pull python3. > > That's mock on Fedora — to run a build in a centos-i386 chroot. Fedora already has python3. I don't see how that can affect what's running in the mock chroot. Is the build inside mock also installing EPEL and python3 somehow? Now? If so, why? And maybe the solution for centos regressions is to run those in mock, with a centos-x86_64 chroot. Without EPEL or python3. -- Kaleb ___ 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
Le jeudi 20 juin 2019 à 06:57 -0400, Kaleb Keithley a écrit : > On Thu, Jun 20, 2019 at 5:27 AM Amar Tumballi Suryanarayan < > atumb...@redhat.com> wrote: > > > On Thu, Jun 20, 2019 at 2:35 PM Niels de Vos > > 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 > > > > wrote: > > > > > > I noticed the issue of smoke is coming only from strfmt-errors job, > > which > > checks for 'epel-6-i386' mock, and fails right now. > > ... > > But we are stuck with strfmt-errors job right now, and looking at > > what it > > was intended to catch in first place, > > ... > > Would be great if disabling strfmt-errors is an option. > > > > strfmt-errors checks that snprintf format stings are correct on both > 32- > and 64-bit platforms. > > Are you ready to drop support on 32-bit platforms? Some distributions > are > dropping 32-bit, but Fedora still supports i686 and armv7hl by > default; it > is possible to drop 32-bit on Fedora but there would be strong > resistance > to doing it I suspect. I also think it would be strange to drop it > in the > middle of a release stream. If you want to drop it for, say, release- > 7 > that'd be a good time to do it. > > strfmt-errors isn't failing generally, AFAICT. The last failure is on > a > release-5 branch build. Since the strfmt-errors runs on a CentOS > machine I > suspect that it's the same issue we have with centos-regression, > which > really goes back to the (misguided IMO) decision to put EPEL and > python3 on > the centos builders. > > misc sent me a list of all the things that "need" python3. > Some/Many/All of > them are for things that run on fedora, e.g. clang- > format. Everything was, > AFAICT, working fine right up to when EPEL and python3 were installed > on > the centos builders. If it was my decision, I'd undo that change. The biggest problem is that mock do pull python3. -- Michael Scherer Sysadmin, Community Infrastructure signature.asc Description: This is a digitally signed message part ___ 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
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 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 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 > > 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 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster
Re: [Gluster-devel] Removing glupy from release 5.7
On Thu, Jun 20, 2019 at 5:27 AM Amar Tumballi Suryanarayan < atumb...@redhat.com> wrote: > On Thu, Jun 20, 2019 at 2:35 PM Niels de Vos 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 wrote: > > > I noticed the issue of smoke is coming only from strfmt-errors job, which > checks for 'epel-6-i386' mock, and fails right now. > ... > But we are stuck with strfmt-errors job right now, and looking at what it > was intended to catch in first place, > ... > Would be great if disabling strfmt-errors is an option. > strfmt-errors checks that snprintf format stings are correct on both 32- and 64-bit platforms. Are you ready to drop support on 32-bit platforms? Some distributions are dropping 32-bit, but Fedora still supports i686 and armv7hl by default; it is possible to drop 32-bit on Fedora but there would be strong resistance to doing it I suspect. I also think it would be strange to drop it in the middle of a release stream. If you want to drop it for, say, release-7 that'd be a good time to do it. strfmt-errors isn't failing generally, AFAICT. The last failure is on a release-5 branch build. Since the strfmt-errors runs on a CentOS machine I suspect that it's the same issue we have with centos-regression, which really goes back to the (misguided IMO) decision to put EPEL and python3 on the centos builders. misc sent me a list of all the things that "need" python3. Some/Many/All of them are for things that run on fedora, e.g. clang-format. Everything was, AFAICT, working fine right up to when EPEL and python3 were installed on the centos builders. If it was my decision, I'd undo that change. ___ 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
On Thu, Jun 20, 2019 at 3:20 PM Niels de Vos 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 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 > 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 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 < > msche...@redhat.com > > > > > > > > > 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 < > > > > > > > > > > kkeit...@redhat.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi > > > Suryanarayan < > > > > > > > > > > > atumb...@redhat.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We recently noticed that in one o
Re: [Gluster-devel] Removing glupy from release 5.7
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 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 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 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. > 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. Niels > > Regards, > > > Niels > > > > > > > > > > > > > > Niels > > > > > > > > > > > > > > > > > > Regards, > > > > > Amar > > > > > > > > > > On Thu, Jun 13, 2019 at 7:26 PM Michael Scherer > > > > > > 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 < > > > > > > > > > kkeit...@redhat.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi > > Suryanarayan < > > > > > > > > > > atumb...@redhat.com> 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 > > > > > > > >
Re: [Gluster-devel] Removing glupy from release 5.7
On Thu, Jun 20, 2019 at 2:35 PM Niels de Vos 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 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 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. 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. Would be great if disabling strfmt-errors is an option. Regards, > Niels > > > > > > > > > Niels > > > > > > > > > > > > > > Regards, > > > > Amar > > > > > > > > On Thu, Jun 13, 2019 at 7:26 PM Michael Scherer > > > > 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 < > > > > > > > > kkeit...@redhat.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi > Suryanarayan < > > > > > > > > > atumb...@redhat.com> 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 requir
Re: [Gluster-devel] Removing glupy from release 5.7
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 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 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. The backport might become relevant while running tests on environments where there is no python2. Niels > > > > Niels > > > > > > > > > > Regards, > > > Amar > > > > > > On Thu, Jun 13, 2019 at 7:26 PM Michael Scherer > > 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 < > > > > > > > kkeit...@redhat.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan < > > > > > > > > atumb...@redhat.com> 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
Re: [Gluster-devel] Removing glupy from release 5.7
On Thu, Jun 20, 2019 at 1:13 PM Niels de Vos 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. > Niels > > > > > > Regards, > > Amar > > > > On Thu, Jun 13, 2019 at 7:26 PM Michael Scherer > 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 < > > > > > > kkeit...@redhat.com> wrote: > > > > > > > > > > > > > > > > > > > > On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan < > > > > > > > atumb...@redhat.com> 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 > > > Bridg
Re: [Gluster-devel] Removing glupy from release 5.7
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. Niels > > Regards, > Amar > > On Thu, Jun 13, 2019 at 7:26 PM Michael Scherer 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 < > > > > > kkeit...@redhat.com> wrote: > > > > > > > > > > > > > > > > > On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan < > > > > > > atumb...@redhat.com> 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 > > Gluster-devel@gluster.org > > https://lists.gluster.org/mailman/listinfo/gluster-devel > > > > > > -- > 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/
Re: [Gluster-devel] Removing glupy from release 5.7
Hi Amar, I have done the above request earlier with release 5 and still it fails. Patch: https://review.gluster.org/#/c/glusterfs/+/22855/ build log for failure: https://build.gluster.org/job/strfmt_errors/18889/artifact/RPMS/el6/i686/build.log The failure is related to building. So we need to fix the python 3 compatibility issues with release 5 as well. The build uses python3 and gluster relies on python2. I'm not sure if the patches to make gluster python3 compatible have made its way to release 5 and 6. If not then we have to work on that and make the build changes necessary to start consuming python3 for release branches. Or we have to make the build script smarter to use python 2 for release branches and python 3 for master. On Thu, Jun 20, 2019 at 11:38 AM 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? > > Regards, > Amar > > On Thu, Jun 13, 2019 at 7:26 PM Michael Scherer 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 < >> > > > kkeit...@redhat.com> wrote: >> > > > >> > > > > >> > > > > On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan < >> > > > > atumb...@redhat.com> 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 >> Gluste
Re: [Gluster-devel] Removing glupy from release 5.7
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? Regards, Amar On Thu, Jun 13, 2019 at 7:26 PM Michael Scherer 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 < > > > > kkeit...@redhat.com> wrote: > > > > > > > > > > > > > > On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan < > > > > > atumb...@redhat.com> 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 > Gluster-devel@gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-devel > > -- 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 Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
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 < > > > kkeit...@redhat.com> wrote: > > > > > > > > > > > On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan < > > > > atumb...@redhat.com> 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 signature.asc Description: This is a digitally signed message part ___ 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
Le jeudi 13 juin 2019 à 05:55 -0700, Kaleb Keithley a écrit : > On Thu, Jun 13, 2019 at 2:22 AM Deepshikha Khandelwal < > dkhan...@redhat.com> > wrote: > > > On Thu, Jun 13, 2019 at 10:06 AM Kaleb Keithley < > > kkeit...@redhat.com> > > wrote: > > > > > On Wed, Jun 12, 2019 at 8:13 PM Deepshikha Khandelwal < > > > dkhan...@redhat.com> wrote: > > > > > > > On Thu, Jun 13, 2019 at 4:41 AM Kaleb Keithley < > > > > kkeit...@redhat.com> > > > > wrote: > > > > > > > > > On Wed, Jun 12, 2019 at 11:36 AM Kaleb Keithley < > > > > > kkeit...@redhat.com> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We need to figure out why? BTW, my CentOS 7 box is up to date and > > > does > > > not have any version of python3. I would have to use the SCL or > > > EPEL to get > > > it. > > > > > > What changed on June 5th? Between > > > https://build.gluster.org/job/centos7-regression/6309/consoleFull > > > and > > > https://build.gluster.org/job/centos7-regression/6310/consoleFull > > > ? > > > > > > > Yes, you are right. OS got upgrade to newer version on 5th June. It > > has > > EPEL repo enabled for various other things. > > > > What other things? Are there not python2 versions of these things? > That work just as well as the pyton3 versions? Mock pull python3: [root@builder11 ~]# LC_ALL=C rpm -e --test python36-rpm error: Failed dependencies: python36-rpm is needed by (installed) mock-1.4.16-1.el7.noarch And I think it would be ill advised to backport a EOL version of mock with python 2 on the builders. > Adding EPEL and installing python3 on the centos boxes seems like a > mistake to me, if only because it has broken the builds there. Was > there any discussion of adding EPEL and python3 ? I don't recall > seeing any. We have EPEL for: - munin - nagios - golang - clang, cppcheck - mock - nginx nginx could be removed now (that's kinda legacy). The rest look like very much stuff we use, so I think EPEL is here to stay. > But since EPEL was added, one possible work-around would be to do the > build > in mock. The detection logic is hitting a corner case (granted, that's one that changed under people feet). There is a 2 step approach: - detect the most recent version of python - verify that there is headers for that python version But having python 3 do not mean we want to use that one for building. So I think the right autodetection would be to - list all version of python - take the most recent one with -devel installed (eg, 1 loop that check 2 things, instead of 1 loop for version, and a check after). Or, as a work around, we should be explicit on the python version with a configure switch, so we can be sure we test and build the right one, since the autodetection hit a corner case. -- Michael Scherer Sysadmin, Community Infrastructure signature.asc Description: This is a digitally signed message part ___ 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
On Thu, Jun 13, 2019 at 2:22 AM Deepshikha Khandelwal wrote: > On Thu, Jun 13, 2019 at 10:06 AM Kaleb Keithley > wrote: > >> On Wed, Jun 12, 2019 at 8:13 PM Deepshikha Khandelwal < >> dkhan...@redhat.com> wrote: >> >>> On Thu, Jun 13, 2019 at 4:41 AM Kaleb Keithley >>> wrote: >>> On Wed, Jun 12, 2019 at 11:36 AM Kaleb Keithley wrote: > > > >> We need to figure out why? BTW, my CentOS 7 box is up to date and does >> not have any version of python3. I would have to use the SCL or EPEL to get >> it. >> >> What changed on June 5th? Between >> https://build.gluster.org/job/centos7-regression/6309/consoleFull and >> https://build.gluster.org/job/centos7-regression/6310/consoleFull? >> > Yes, you are right. OS got upgrade to newer version on 5th June. It has > EPEL repo enabled for various other things. > What other things? Are there not python2 versions of these things? That work just as well as the pyton3 versions? Adding EPEL and installing python3 on the centos boxes seems like a mistake to me, if only because it has broken the builds there. Was there any discussion of adding EPEL and python3 ? I don't recall seeing any. But since EPEL was added, one possible work-around would be to do the build in mock. -- Kaleb ___ 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
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 wrote: > > > > > > > > On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan < > > > atumb...@redhat.com> 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. 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
On Thu, Jun 13, 2019 at 10:06 AM Kaleb Keithley wrote: > > > On Wed, Jun 12, 2019 at 8:13 PM Deepshikha Khandelwal > wrote: > >> >> On Thu, Jun 13, 2019 at 4:41 AM Kaleb Keithley >> wrote: >> >>> >>> >>> On Wed, Jun 12, 2019 at 11:36 AM Kaleb Keithley >>> wrote: >>> On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan < atumb...@redhat.com> 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. >>> >> >> centos-regression machines have 'CentOS Linux release 7.6.1810 (Core)' >> and using python3.6. Looking at the tracebacks when compiling we confirmed >> that it is picking up python3.6 somehow. >> > > We need to figure out why? BTW, my CentOS 7 box is up to date and does not > have any version of python3. I would have to use the SCL or EPEL to get it. > > What changed on June 5th? Between > https://build.gluster.org/job/centos7-regression/6309/consoleFull and > https://build.gluster.org/job/centos7-regression/6310/consoleFull? > Yes, you are right. OS got upgrade to newer version on 5th June. It has EPEL repo enabled for various other things. Can we make changes in configure.ac file (python version specific to the branches) rather than falling back to python2 for other branches too? > > 6309 was the last centos-regression with python2.7. 6310 and all > subsequent centos-regressions have been built with python3.6. > > Somebody added EPEL! Do we not have a record of the changes made and who > made them? > > And BTW, this affects more than just glusterfs-5, it's affecting all > versions: glusterfs-4.1, glusterfs-5, glusterfs-6, and master. > > >> To resolve this issue either we can remove glupy from the release(which >> is dead anyways) or install glupy on the instances. >> > > Or you can resolve where python36 came from and undo the change that > introduced it. > > At the risk of being repetitious – reiterating what Niels said – it's > highly unusual to remove features in a bug fix update. > > It's also unusual to have switched to python3 on rhel7 like this. Was > there any discussion of such a change? If there was I seem to have missed > it. > > I suggest figuring out where python3.6 on rhel7 came from. Fix that > first. Removing glupy is a bandaid over a unrelated problem. Once the real > problem is fixed then there can be a separate discussion about removing the > glupy feature in glusterfs-5. > > -- > > Kaleb > ___ 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
On Wed, Jun 12, 2019 at 04:09:55PM -0700, Kaleb Keithley wrote: > On Wed, Jun 12, 2019 at 11:36 AM Kaleb Keithley wrote: > > > > > On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan < > > atumb...@redhat.com> 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? I guess we could force the release-4.1 and release-5 branches to use python2 only. This might be done by exporting PYTHON=/usr/bin/python2 in the environment where './configure' is run. That would likely require changes to multiple Jenkins jobs... 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
On Wed, Jun 12, 2019 at 8:13 PM Deepshikha Khandelwal wrote: > > On Thu, Jun 13, 2019 at 4:41 AM Kaleb Keithley > wrote: > >> >> >> On Wed, Jun 12, 2019 at 11:36 AM Kaleb Keithley >> wrote: >> >>> >>> On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan < >>> atumb...@redhat.com> 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. >> > > centos-regression machines have 'CentOS Linux release 7.6.1810 (Core)' and > using python3.6. Looking at the tracebacks when compiling we confirmed that > it is picking up python3.6 somehow. > We need to figure out why? BTW, my CentOS 7 box is up to date and does not have any version of python3. I would have to use the SCL or EPEL to get it. What changed on June 5th? Between https://build.gluster.org/job/centos7-regression/6309/consoleFull and https://build.gluster.org/job/centos7-regression/6310/consoleFull? 6309 was the last centos-regression with python2.7. 6310 and all subsequent centos-regressions have been built with python3.6. Somebody added EPEL! Do we not have a record of the changes made and who made them? And BTW, this affects more than just glusterfs-5, it's affecting all versions: glusterfs-4.1, glusterfs-5, glusterfs-6, and master. > To resolve this issue either we can remove glupy from the release(which is > dead anyways) or install glupy on the instances. > Or you can resolve where python36 came from and undo the change that introduced it. At the risk of being repetitious – reiterating what Niels said – it's highly unusual to remove features in a bug fix update. It's also unusual to have switched to python3 on rhel7 like this. Was there any discussion of such a change? If there was I seem to have missed it. I suggest figuring out where python3.6 on rhel7 came from. Fix that first. Removing glupy is a bandaid over a unrelated problem. Once the real problem is fixed then there can be a separate discussion about removing the glupy feature in glusterfs-5. -- Kaleb ___ 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
On Thu, Jun 13, 2019 at 4:41 AM Kaleb Keithley wrote: > > > On Wed, Jun 12, 2019 at 11:36 AM Kaleb Keithley > wrote: > >> >> On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan < >> atumb...@redhat.com> 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. > centos-regression machines have 'CentOS Linux release 7.6.1810 (Core)' and using python3.6. Looking at the tracebacks when compiling we confirmed that it is picking up python3.6 somehow. To resolve this issue either we can remove glupy from the release(which is dead anyways) or install glupy on the instances. > > -- > > Kaleb > ___ > > 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@gluster.org > 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 Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
On Wed, Jun 12, 2019 at 11:36 AM Kaleb Keithley wrote: > > On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan < > atumb...@redhat.com> 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. -- Kaleb ___ 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan < atumb...@redhat.com> 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. -- Kaleb ___ 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
On Wed, Jun 12, 2019 at 8:42 PM Niels de Vos wrote:
> On Wed, Jun 12, 2019 at 07:54:17PM +0530, Hari Gowtham wrote:
> > We haven't sent any patch to fix it.
> > Waiting for the decision to be made.
> > The bz: https://bugzilla.redhat.com/show_bug.cgi?id=1719778
> > The link to the build log:
> >
> https://build.gluster.org/job/strfmt_errors/1/artifact/RPMS/el6/i686/build.log
> >
> > The last few messages in the log:
> >
> > config.status: creating xlators/features/changelog/lib/src/Makefile
> > config.status: creating xlators/features/changetimerecorder/Makefile
> > config.status: creating xlators/features/changetimerecorder/src/Makefile
> > BUILDSTDERR: config.status: error: cannot find input file:
> > xlators/features/glupy/Makefile.in
> > RPM build errors:
> > BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.kGZI5V (%build)
> > BUILDSTDERR: Bad exit status from /var/tmp/rpm-tmp.kGZI5V (%build)
> > Child return code was: 1
> > EXCEPTION: [Error()]
> > Traceback (most recent call last):
> > File "/usr/lib/python3.6/site-packages/mockbuild/trace_decorator.py",
> > line 96, in trace
> > result = func(*args, **kw)
> > File "/usr/lib/python3.6/site-packages/mockbuild/util.py", line 736,
> > in do_with_status
> > raise exception.Error("Command failed: \n # %s\n%s" % (command,
> > output), child.returncode)
> > mockbuild.exception.Error: Command failed:
> > # bash --login -c /usr/bin/rpmbuild -bb --target i686 --nodeps
> > /builddir/build/SPECS/glusterfs.spec
>
> Those messages are caused by missing files. The 'make dist' that
> generates the tarball in the previous step did not included the glupy
> files.
>
> https://build.gluster.org/job/strfmt_errors/1/console contains the
> following message:
>
> configure: WARNING:
>
> -
> cannot build glupy. python 3.6 and python-devel/python-dev
> package are required.
>
> -
>
> I am not sure if there have been any recent backports to release-5 that
> introduced this behaviour. Maybe it is related to the builder where the
> tarball is generated. The job seems to detect python-3.6.8, which is not
> included in CentOS-7 for all I know?
>
>
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.
-Amar
> Maybe someone else understands how this can happen?
>
> HTH,
> Niels
>
>
> >
> > On Wed, Jun 12, 2019 at 7:04 PM Niels de Vos wrote:
> > >
> > > On Wed, Jun 12, 2019 at 02:44:04PM +0530, Hari Gowtham wrote:
> > > > Hi,
> > > >
> > > > Due to the recent changes we made. we have a build issue because of
> glupy.
> > > > As glupy is already removed from master, we are thinking of removing
> > > > it in 5.7 as well rather than fixing the issue.
> > > >
> > > > The release of 5.7 will be delayed as we have send a patch to fix
> this issue.
> > > > And if anyone has any concerns, do let us know.
> > >
> > > Could you link to the BZ with the build error and patches that attempt
> > > fixing it?
> > >
> > > We normally do not remove features with minor updates. Fixing the build
> > > error would be the preferred approach.
> > >
> > > Thanks,
> > > Niels
> >
> >
> >
> > --
> > Regards,
> > Hari Gowtham.
> ___
>
> 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@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
>
--
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
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
On Wed, Jun 12, 2019 at 07:54:17PM +0530, Hari Gowtham wrote:
> We haven't sent any patch to fix it.
> Waiting for the decision to be made.
> The bz: https://bugzilla.redhat.com/show_bug.cgi?id=1719778
> The link to the build log:
> https://build.gluster.org/job/strfmt_errors/1/artifact/RPMS/el6/i686/build.log
>
> The last few messages in the log:
>
> config.status: creating xlators/features/changelog/lib/src/Makefile
> config.status: creating xlators/features/changetimerecorder/Makefile
> config.status: creating xlators/features/changetimerecorder/src/Makefile
> BUILDSTDERR: config.status: error: cannot find input file:
> xlators/features/glupy/Makefile.in
> RPM build errors:
> BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.kGZI5V (%build)
> BUILDSTDERR: Bad exit status from /var/tmp/rpm-tmp.kGZI5V (%build)
> Child return code was: 1
> EXCEPTION: [Error()]
> Traceback (most recent call last):
> File "/usr/lib/python3.6/site-packages/mockbuild/trace_decorator.py",
> line 96, in trace
> result = func(*args, **kw)
> File "/usr/lib/python3.6/site-packages/mockbuild/util.py", line 736,
> in do_with_status
> raise exception.Error("Command failed: \n # %s\n%s" % (command,
> output), child.returncode)
> mockbuild.exception.Error: Command failed:
> # bash --login -c /usr/bin/rpmbuild -bb --target i686 --nodeps
> /builddir/build/SPECS/glusterfs.spec
Those messages are caused by missing files. The 'make dist' that
generates the tarball in the previous step did not included the glupy
files.
https://build.gluster.org/job/strfmt_errors/1/console contains the
following message:
configure: WARNING:
-
cannot build glupy. python 3.6 and python-devel/python-dev package
are required.
-
I am not sure if there have been any recent backports to release-5 that
introduced this behaviour. Maybe it is related to the builder where the
tarball is generated. The job seems to detect python-3.6.8, which is not
included in CentOS-7 for all I know?
Maybe someone else understands how this can happen?
HTH,
Niels
>
> On Wed, Jun 12, 2019 at 7:04 PM Niels de Vos wrote:
> >
> > On Wed, Jun 12, 2019 at 02:44:04PM +0530, Hari Gowtham wrote:
> > > Hi,
> > >
> > > Due to the recent changes we made. we have a build issue because of glupy.
> > > As glupy is already removed from master, we are thinking of removing
> > > it in 5.7 as well rather than fixing the issue.
> > >
> > > The release of 5.7 will be delayed as we have send a patch to fix this
> > > issue.
> > > And if anyone has any concerns, do let us know.
> >
> > Could you link to the BZ with the build error and patches that attempt
> > fixing it?
> >
> > We normally do not remove features with minor updates. Fixing the build
> > error would be the preferred approach.
> >
> > Thanks,
> > Niels
>
>
>
> --
> Regards,
> Hari Gowtham.
___
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@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
We haven't sent any patch to fix it.
Waiting for the decision to be made.
The bz: https://bugzilla.redhat.com/show_bug.cgi?id=1719778
The link to the build log:
https://build.gluster.org/job/strfmt_errors/1/artifact/RPMS/el6/i686/build.log
The last few messages in the log:
config.status: creating xlators/features/changelog/lib/src/Makefile
config.status: creating xlators/features/changetimerecorder/Makefile
config.status: creating xlators/features/changetimerecorder/src/Makefile
BUILDSTDERR: config.status: error: cannot find input file:
xlators/features/glupy/Makefile.in
RPM build errors:
BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.kGZI5V (%build)
BUILDSTDERR: Bad exit status from /var/tmp/rpm-tmp.kGZI5V (%build)
Child return code was: 1
EXCEPTION: [Error()]
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/mockbuild/trace_decorator.py",
line 96, in trace
result = func(*args, **kw)
File "/usr/lib/python3.6/site-packages/mockbuild/util.py", line 736,
in do_with_status
raise exception.Error("Command failed: \n # %s\n%s" % (command,
output), child.returncode)
mockbuild.exception.Error: Command failed:
# bash --login -c /usr/bin/rpmbuild -bb --target i686 --nodeps
/builddir/build/SPECS/glusterfs.spec
On Wed, Jun 12, 2019 at 7:04 PM Niels de Vos wrote:
>
> On Wed, Jun 12, 2019 at 02:44:04PM +0530, Hari Gowtham wrote:
> > Hi,
> >
> > Due to the recent changes we made. we have a build issue because of glupy.
> > As glupy is already removed from master, we are thinking of removing
> > it in 5.7 as well rather than fixing the issue.
> >
> > The release of 5.7 will be delayed as we have send a patch to fix this
> > issue.
> > And if anyone has any concerns, do let us know.
>
> Could you link to the BZ with the build error and patches that attempt
> fixing it?
>
> We normally do not remove features with minor updates. Fixing the build
> error would be the preferred approach.
>
> Thanks,
> Niels
--
Regards,
Hari Gowtham.
___
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@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removing glupy from release 5.7
On Wed, Jun 12, 2019 at 02:44:04PM +0530, Hari Gowtham wrote: > Hi, > > Due to the recent changes we made. we have a build issue because of glupy. > As glupy is already removed from master, we are thinking of removing > it in 5.7 as well rather than fixing the issue. > > The release of 5.7 will be delayed as we have send a patch to fix this issue. > And if anyone has any concerns, do let us know. Could you link to the BZ with the build error and patches that attempt fixing it? We normally do not remove features with minor updates. Fixing the build error would be the preferred approach. Thanks, 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
