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@xxxxxxxxxx> > > 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@xxxxxxxxxx> > > > > 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@xxxxxxxxxxx > > > 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@xxxxxxxxxxx > 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@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-devel
