Le jeudi 13 juin 2019 à 05:55 -0700, Kaleb Keithley a écrit : > On Thu, Jun 13, 2019 at 2:22 AM Deepshikha Khandelwal < > dkhandel@xxxxxxxxxx> > wrote: > > > On Thu, Jun 13, 2019 at 10:06 AM Kaleb Keithley < > > kkeithle@xxxxxxxxxx> > > wrote: > > > > > On Wed, Jun 12, 2019 at 8:13 PM Deepshikha Khandelwal < > > > dkhandel@xxxxxxxxxx> wrote: > > > > > > > On Thu, Jun 13, 2019 at 4:41 AM Kaleb Keithley < > > > > kkeithle@xxxxxxxxxx> > > > > wrote: > > > > > > > > > On Wed, Jun 12, 2019 at 11:36 AM Kaleb Keithley < > > > > > kkeithle@xxxxxxxxxx> > > > > > 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
Attachment:
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@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-devel
