[Gluster-devel] Removing glupy from release 5.7

Thu Jul 4 14:20:56 UTC 2019

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 <mscherer at redhat.com>
> > wrote:
> > 
> > > Le jeudi 20 juin 2019 à 08:38 -0400, Kaleb Keithley a écrit :
> > > > On Thu, Jun 20, 2019 at 7:39 AM Michael Scherer <
> > > > mscherer at 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 at 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 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 at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
> 