1. 15 Oct, 2020 2 commits
    • Kirill Smelkov's avatar
      ZEO: Factor it to separate component · c1ad7805
      Kirill Smelkov authored
      We already patch ZEO4 with TCP_NODELAY patch (see 5cf4cf1f "ERP5:
      enable TCP_NODELAY for ZEO") and we will need to backport more patches
      to ZEO4 branch for wendelin.core 2 to work correctly.
      
      It's not only software/neoppod which uses ZEO, and it is not convenient for
      all other software-releases to inherit from neoppod to use correct
      version and build of ZEO egg. For this reason factor out details of ZEO
      egg building into component/ZEO and let users use ${ZEO:egg} where ZEO
      is needed. This way ZEO will be correctly installed for all users.
      
      This patch should be a non-functional change. We switch to
      nexedi/ZEO@5114f909 revision which corresponds to ZEO 4.3.1 +
      TCP_NODELAY.patch
      
      Adding other patches to ZEO4 needed by wendelin.core 2 will be done as a
      separate step.
      c1ad7805
    • Julien Muchembled's avatar
      Revert "zodbpickle: v↑ (1.0.4 -> 2.0.0)" · 27f574bc
      Julien Muchembled authored
      This reverts commit 1c2d1c0a.
      because NEO is not ready for such change.
      27f574bc
  2. 14 Oct, 2020 5 commits
  3. 13 Oct, 2020 3 commits
  4. 12 Oct, 2020 4 commits
    • Thomas Gambier's avatar
      d80168bf
    • Thomas Gambier's avatar
      More slaprunner promises · 5486ae80
      Thomas Gambier authored
      See merge request nexedi/slapos!833
      5486ae80
    • Julien Muchembled's avatar
    • Thomas Gambier's avatar
      Revert "gcc: make the ld wrapper add paths via -rpath if there's already an -rpath arg" · 9a7c08e0
      Thomas Gambier authored
      This reverts commit 3d12ddae.
      
      The commit was instroducing errors in compilation or at runtime.
      
      Compilation error were like (for cmake in Debian 8 machine):
      [ 99%] Built target CTestLib
      [100%] Built target ctest
      Install the project...
      bin/cmake: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by bin/cmake)
      bin/cmake: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by bin/cmake)
      Makefile:72: recipe for target 'install' failed
      make: *** [install] Error 1
      cmake: Command 'set -e;make  install' returned non-zero exit status 2
      cmake: Compilation error. The package is left as is at /srv/slapgrid/slappart61/srv/runner/shared/cmake/9fc4b0e8f4f03ce17eb7ef43525d2238__compile__/cmake-3.7.2 where you can inspect what went wrong.
      
      Runtime errors were like (for mariadb in Debian 9):
      Traceback (most recent call last):
        File "/srv/slapgrid/slappart13/srv/testnode/dfg/soft/e2d325c0fcfb592bc760fe363ac5b17a/parts/slapos.core-repository/slapos/testing/testcase.py", line 168, in setUpModule
          installSoftwareUrlList(cls, [software_url], debug=debug)
        File "/srv/slapgrid/slappart13/srv/testnode/dfg/soft/e2d325c0fcfb592bc760fe363ac5b17a/parts/slapos.core-repository/slapos/testing/testcase.py", line 378, in installSoftwareUrlList
          checkSoftware(cls.slap, software_url)
        File "/srv/slapgrid/slappart13/srv/testnode/dfg/soft/e2d325c0fcfb592bc760fe363ac5b17a/parts/slapos.core-repository/slapos/testing/testcase.py", line 336, in checkSoftware
          raise RuntimeError('\n'.join(error_list))
      RuntimeError: /srv/slapgrid/slappart13/srv/testnode/dfg/inst/test0-0/tmp/shared/mariadb/46cf3950f79675ddccafc1c99a13e734/bin/mysql_ldb has some not found libraries:
      /srv/slapgrid/slappart13/srv/testnode/dfg/inst/test0-0/tmp/shared/mariadb/46cf3950f79675ddccafc1c99a13e734/bin/mysql_ldb: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by /srv/slapgrid/slappart13/srv/testnode/dfg/inst/test0-0/tmp/shared/mariadb/46cf3950f79675ddccafc1c99a13e734/bin/mysql_ldb)
      /srv/slapgrid/slappart13/srv/testnode/dfg/inst/test0-0/tmp/shared/mariadb/46cf3950f79675ddccafc1c99a13e734/bin/sst_dump has some not found libraries:
      /srv/slapgrid/slappart13/srv/testnode/dfg/inst/test0-0/tmp/shared/mariadb/46cf3950f79675ddccafc1c99a13e734/bin/sst_dump: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by /srv/slapgrid/slappart13/srv/testnode/dfg/inst/test0-0/tmp/shared/mariadb/46cf3950f79675ddccafc1c99a13e734/bin/sst_dump)
      9a7c08e0
  5. 09 Oct, 2020 5 commits
  6. 08 Oct, 2020 8 commits
  7. 06 Oct, 2020 4 commits
  8. 05 Oct, 2020 2 commits
  9. 02 Oct, 2020 4 commits
    • Julien Muchembled's avatar
      version up: Debian 10 netinst · 8dfa5add
      Julien Muchembled authored
      8dfa5add
    • Jérome Perrin's avatar
      f56c476a
    • Jérome Perrin's avatar
      software/theia: clear venv when installing python language server · 31dc8c63
      Jérome Perrin authored
      Prevent this kind of errors when first installation fail:
      
          Error: [Errno 13] Permission denied: 'parts/python-language-server/bin/activate'
      
      by using --clear the virtualenv is recreated from scratch if the command failed
      for some reason.
      31dc8c63
    • Jérome Perrin's avatar
      component/mariadb: go back to mariadb 10.3.22 · b8d3131b
      Jérome Perrin authored
      We are observing mariadb crashes in ERP5 with 10.4, so revert back to 10.3
      
      Crashes errors are:
      
          InnoDB: Assertion failure in file .../mariadb-10.4.14/storage/innobase/lock/lock0lock.cc line 6900
      
      in non debug mode and:
      
          mysqld: .../mariadb-10.4.14/storage/innobase/row/row0sel.cc:4480: dberr_t row_search_mvcc(byte*, page_cur_mode_t, row_prebuilt_t*, ulint, ulint): Assertion `prebuilt->sql_stat_start || trx->state == TRX_STATE_ACTIVE || (prebuilt->table->no_rollback() && trx->state == TRX_STATE_NOT_STARTED)' failed.
      
      in debug mode.
      
      This is an incompatible change for ERP5 instances which might have
      already been running mariadb 10.4, because their database would have
      been updated to 10.4, but mariadb does not support "downgrading".
      Hopefully we don't have such cases, but if that's the case one
      solution seems to dump databases with 10.4 and load in 10.3 and
      I guess in this process the system databases such as "mysql" should
      be excluded from this process.
      b8d3131b
  10. 30 Sep, 2020 3 commits