1. 12 Dec, 2019 1 commit
  2. 10 Dec, 2019 1 commit
    • Jérome Perrin's avatar
      shared: Fix recovery after an interrupted build · 0bb65331
      Jérome Perrin authored
      When build process is interrupted (like when the buildout process
      terminated by SIGKILL), building with shared leave the system in a state
      that looks like installation succeeded, so next execution will assume
      the part was properly installed.
      
      
      The behavior was something like this:
      
      
          if isSharedPartSignatureOK():
            useThisAlreadyInstalledPart()
          else:
            writeSignatureInSharedPart()
            try:
              build()
            except:
              removeSharedPart()
              raise
      
      
      and when program is terminated during build step, the signature is
      there.
      
      The fix is to write signature later, algorithm becomes:
      
      
          if isSharedPartSignatureOK():
            useThisAlreadyInstalledPart()
          else:
            try:
              build()
            except:
              removeSharedPart()
              raise
            writeSignatureInSharedPart()
      
      /reviewed-on !10
      0bb65331
  3. 05 Dec, 2019 1 commit
  4. 02 Oct, 2019 4 commits
  5. 01 Oct, 2019 1 commit
  6. 30 Sep, 2019 1 commit
    • Jérome Perrin's avatar
      Support multiple paths for shared · 3cd08544
      Jérome Perrin authored
      This will allow nested slapos where the inner slapos can re-use shared
      parts from outer slapos, but not write into the outer shared parts.
      
      For compatibility reasons, the syntax of the buildout option changed,
      instead of the old ${buildout:shared-parts} that use to be one path, we
      now use ${buildout:shared-part-list} as a \n separated list of paths.
      All paths can be used to lookup existing parts, only the last one can be
      used to install new parts.
      There is no compatibility with the old option as it was not used much,
      only in profiles which were not really compatible with shared options.
      3cd08544
  7. 26 Sep, 2019 3 commits
  8. 25 Sep, 2019 1 commit
  9. 30 Nov, 2018 3 commits
  10. 29 Oct, 2018 2 commits
  11. 16 Oct, 2018 2 commits
    • Jérome Perrin's avatar
      Do not set any TMP environment variables · 9ca803bb
      Jérome Perrin authored
      This reverts daa833ea ( nexedi/slapos.recipe.cmmi!3 ) and extend it to not set `$TMP` either.
      
      De facto, setting only `$TMP` was never effective ( see also [#20120530-132221B](https://nexedi.erp5.net/bug_module/20120530-132221B) ) and as we saw in nexedi/slapos.recipe.cmmi!3 (comment 67059) it causes more harm than good.
      
      The conclusion so far is that environment variables related to temporary files should be handled by the parent process. The parent process is responsible for providing a directory short enough so that we can create unix sockets in `$TMPDIR`  and to clean up this directory afterwards.
      
      
      In a pure buildout it could be:
      
      ```bash
      tmpdir=$(mktemp -d)
      trap 'rm -rf $tmpdir' SIGINT SIGTERM
      TEMP=$tmpdir TMPDIR=$tmpdir TMP=$tmpdir buildout
      rm -rf $tmpdir
      ```
      
      /reviewed-on nexedi/slapos.recipe.cmmi!8
      9ca803bb
    • Jérome Perrin's avatar
      Don't set TMP environment variable · f101b03b
      Jérome Perrin authored
      It was inconsistent to only set TMP and not TEMP / TEMPDIR. In the case
      of slapos, it should be set by slapos node software
      
      Most installation seem to cleanup tmp properly, so the use case cleaning
      up seem not critical.
      
      This TMP was also used to know what new files have been created, by
      considering files newer that the creation date of this directory.
      Compare the file dates with the creation of the source directory instead
      ( xxx__compile__ )
      f101b03b
  12. 04 Oct, 2018 1 commit
  13. 02 Oct, 2018 2 commits
  14. 19 Sep, 2018 1 commit
  15. 18 Sep, 2018 1 commit
  16. 27 Aug, 2018 2 commits
  17. 22 Aug, 2018 3 commits
  18. 21 Aug, 2018 2 commits
  19. 20 Aug, 2018 1 commit
  20. 01 Aug, 2018 1 commit
  21. 31 Jul, 2018 1 commit
  22. 22 Jun, 2018 1 commit
  23. 31 May, 2018 1 commit
    • Xiaowu Zhang's avatar
      Reimplement shared features · 5239a27d
      Xiaowu Zhang authored
      1.use shared-part in [buildout] section to define shared path
      2.shared option is True or Flase
      3.a magic substitution @@LOCATION@@ is used to for dynamic path
      5239a27d
  24. 28 Mar, 2018 1 commit
    • Jérome Perrin's avatar
      fixup! Fix random test failure with make flags on test node · aa5a651b
      Jérome Perrin authored
      ```
      ======================================================================
      ERROR: /srv/slapgrid/slappart0/parts/slapos.recipe.cmmi/slapos/recipe/cmmi/README.txt
      Doctest: README.txt
      ----------------------------------------------------------------------
      Traceback (most recent call last):
        File "/opt/slapgrid/298b8e2a56fa3803aa68aa4cfe6a3b96/parts/python2.7/lib/python2.7/doctest.py", line 2194, in setUp
          self._dt_setUp(test)
        File "/srv/slapgrid/slappart0/parts/slapos.recipe.cmmi/slapos/recipe/cmmi/tests.py", line 26, in setUp
          os.environ.pop('MAKEFLAGS')
        File "/opt/slapgrid/298b8e2a56fa3803aa68aa4cfe6a3b96/parts/python2.7/lib/python2.7/os.py", line 505, in pop
          return self.data.pop(key, *args)
      KeyError: 'MAKEFLAGS'
      ```
      aa5a651b
  25. 09 Mar, 2018 1 commit
    • Jérome Perrin's avatar
      Fix random test failure with make flags on test node · 36b9d633
      Jérome Perrin authored
      When running under testnode, there was sometimes this failure:
      
      ```
      File "/srv/slapgrid/slappart8/srv/testnode/bee/inst/test0-0/parts/slapos.recipe.cmmi/slapos/recipe/cmmi/README.txt", line 521, in README.txt
      Failed example:
          print(system(buildout))
      Expected:
          Uninstalling package.
          Installing package.
          package: [ENV] CFLAGS = -I/sw/include
          package: [ENV] LDFLAGS = -L/sw/lib -L/some/extra/lib
          package: [ENV] TMP = /sample_buildout/parts/package/tmp
          package: Applying patches
          patching file configure
          patching file Makefile.dist
          patched-configure --prefix=/somewhere/else --with-threads --without-foobar
          building patched package
          installing patched package
          installing patched package-lib
          <BLANKLINE>
      Got:
          Uninstalling package.
          Installing package.
          package: [ENV] CFLAGS = -I/sw/include
          package: [ENV] LDFLAGS = -L/sw/lib -L/some/extra/lib
          package: [ENV] TMP = /sample_buildout/parts/package/tmp
          package: Applying patches
          patching file configure
          patching file Makefile.dist
          patched-configure --prefix=/somewhere/else --with-threads --without-foobar
          building patched package
          installing patched package-lib
          installing patched package
          <BLANKLINE>
      ```
      
      The order of in which `installing patched package-lib` and ` installing patched package` are printed is not always same.
      
      This test does `make install install-lib` with a Makefile containing:
      
      ```
      all:
              @echo building package
      
      install:
              @echo installing package
      
      install-lib:
              @echo installing package-lib
      ```
      
      @vpelletier  and I investigated this and he pointed out that order of parts depends is not stable when make is invoked with `-j` option.
      
      Turned out that [on test node](https://nexedi.erp5.net/test_result_module/20180308-55459479/7) `MAKEFLAGS` is  set to `-j12`.
      
      
      /reviewed-on nexedi/slapos.recipe.cmmi!5
      36b9d633
  26. 07 Mar, 2018 1 commit