fixup! update default SlapOS gcc version to 10.5

software/dream/software.cfg

@@ -16,6 +16,8 @@ parts =
 [gcc]
 # Always build GCC for Fortran (see openblas).
 max_version = 0
+
+[gcc:python2]
 # also use old gcc version for old scipy version used in python2
 part = gcc-8.5
 

software/neoppod/software-common.cfg

@@ -32,7 +32,7 @@ parts =
 [python]
 part = python2.7
 
-[gcc]
+[gcc:python2]
 # use old gcc version for old scipy version used in python2
 max_version = 8
 part = gcc-8.5

[Xavier Thompson]

Hello!

This change is the source of a bug that was hard to track down:

When reinstalling erp5 SR in place (with slapos node software --all or slapos node software --only <sr-url>), so as to trigger buildout execution again, I noticed that gcc-10.5 was recompiled because its buildout signature changed in a weird way: the previously installed part had python:<hash> in the signature but the part-to-be-reinstalled not, and this change was the logged reason for reinstalling gcc-10.5.

Here's what actually happens:

1. [slapgrid] buildout bootstrap => creates bin/buildout with #! python3-from-system
2. [slapgrid] bin/buildout => before rebootstrap:
   • [slapos.rebootstrap] => install part python only (as if ${buildout:parts} == python)
   • [slapos.rebootstrap] => python pulls section gcc and sys.executable==python3 therefore ${gcc:part} == gcc-10.5
   • [slapos.rebootstrap] => python's init calls barrier() after section gcc-10.5 is initialized, therefore this does not result in python:<hash> being added to gcc-10.5's __buildout_signature__
   • [slapos.rebootstrap] => creates bin/buildout with #! python2-just-installed
3. [slapgrid] bin/buildout => after rebootstrap:
   • install all ${buildout:parts}
   • sys.executable==python2 therefore [${gcc:part} == gcc-8.5]
   • part python occurs first in ${buildout:parts}, pulls gcc which pulls gcc-8.5, and calls barrier()
   • gcc-10.5 is initialized much later being pulled by inkscape, and therefore is affected by barrier(): it now has python:<hash> in its __buildout_signature__
   • I didn't check but am pretty sure gcc-10.5 is recompiled after rebootstrap because its signature changed
   • worse: I didn't check but am pretty sure python is recompiled after rebootstrap because its gcc dependency changes
4. [slapgrid] buildout bootstrap => creates bin/buildout with #! python3-from-system
5. [slapgrid] bin/buildout => before rebootstrap:
   • gcc-10.5 is recompiled for no reason because python:<hash> is removed from its signature
   • python is recompiled because its signature changed: it depends through gcc on gcc-10.5 instead of gcc-8.5

Note: part of the problem (step 5) does not occur if step 4 does not occur, and even with slapos node software --all it's not systematic: slapgrid does not always call buildout bootstrap.

But even if erp5 is never reinstalled in place, I'm pretty sure the first compilation compiles gcc-10.5 and python twice for no reason.

A possible solution: put

[gcc]
part = gcc-8.5

in slapos-py2.cfg

In any case: never do [gcc:python2] (or [gcc:python3]) ever, because since gcc is installed before rebootstrap, this can trigger it being reinstalled after because python version changed.

[Xavier Thompson]

/cc @tomo

[Jérome Perrin]

A possible solution: put

[gcc]
part = gcc-8.5

in slapos-py2.cfg

I'm not commenting on whether this is good fix or not, but about a potential difficulty with this approach (and maybe all possible approaches ;)). For ERP5, we are still in a configuration where there is no software-py2.cfg, software.cfg is python2 and software-py3.cfg extends it (so software-py3.cfg extends slapos-py2.cfg), if this is complicating things the fix here, we can reorganise profiles here, maybe have a "common" that py2 and py3 would extend.

---

These days, testnodes feel really slow, I have not investigated why. Can it be because of this ?

[Xavier Thompson]

For ERP5, we are still in a configuration where there is no software-py2.cfg, software.cfg is python2 and software-py3.cfg extends it (so software-py3.cfg extends slapos-py2.cfg), if this is complicating things the fix here, we can reorganise profiles here, maybe have a "common" that py2 and py3 would extend.

Looking at software-py3, it seems it extends stack/erp5/buildout.cfg directly, not software.cfg. So this does not seem like an issue.

Moreover:

1. with slapos-py2.cfg, what determines if an SR uses Python2 is whether slapos-py2.cfg is in the extends tree and appears after component/defaults.cfg when walking the tree depth first (with the current implementation of the extends algorithm), i.e. if slapos-py2.cfg overrides component/defaults.cfg.
2. Exactly the same, if slapos-py2.cfg contains part = gcc-8.5, what determines if gcc-8.5 applies is whether slapos-py2.cfg overrides (i.e. appears after) component/defaults.cfg

So gcc-8.5 will apply exactly when Python2 applies in any case :)

---

These days, testnodes feel really slow, I have not investigated why. Can it be because of this ?

The thought crossed my mind too.

[Jérome Perrin]

Oh sorry you seem to be right :) stack/erp5/buildout.cfg extends software/neoppod/software-common.cfg which contains this gcc:python2 but if we remove it and put it only in slapos-py2.cfg as you suggest it probably work.

Are you planning to try this ? ( I am not )

[Thomas Gambier]

/cc @jm

yes, could you try this @xavier_thompson thanks :)