1. 06 Aug, 2019 2 commits
  2. 26 Jul, 2019 3 commits
  3. 23 Jul, 2019 2 commits
  4. 24 Jun, 2019 3 commits
  5. 21 Jun, 2019 1 commit
  6. 20 Jun, 2019 1 commit
  7. 19 Jun, 2019 1 commit
  8. 04 Jun, 2019 1 commit
  9. 31 May, 2019 2 commits
  10. 22 May, 2019 1 commit
  11. 16 May, 2019 1 commit
  12. 25 Apr, 2019 1 commit
  13. 17 Apr, 2019 1 commit
    • Jérome Perrin's avatar
      erp5: Fix bug with too many apache Listen · 70b3e0e3
      Jérome Perrin authored
      A regression in the apache entries for testrunner used one apache port
      for each zope - not one for each family as what was intended.
      There was also a problem that these apache ports were used even when no
      testrunner.
      70b3e0e3
  14. 10 Apr, 2019 1 commit
  15. 09 Apr, 2019 1 commit
  16. 02 Apr, 2019 1 commit
  17. 27 Mar, 2019 4 commits
  18. 12 Mar, 2019 2 commits
  19. 01 Mar, 2019 2 commits
  20. 15 Feb, 2019 1 commit
  21. 21 Jan, 2019 1 commit
  22. 11 Jan, 2019 1 commit
  23. 02 Jan, 2019 2 commits
  24. 27 Dec, 2018 1 commit
    • Vincent Pelletier's avatar
      stack/erp5: Replicate based on slave_pos, not current_pos · 58caaffc
      Vincent Pelletier authored
      The query present in the sql dump sets gtid_slave_pos, which is used by
      slave_pos. current_pos relies on gtid_current_pos, which is not set here
      and hence fails to initiate replication.
      Another (unintended) effect of using slave_pos is that queries run on the
      slave will not break replication. There should be no reason to run queries
      on slave (at least, data & schema modification queries while replication
      is active), so it would seem better to fail the replication immediately in
      order to detect this. So this may not be the best solution - but at least
      this fixes this script.
      58caaffc
  25. 24 Dec, 2018 1 commit
  26. 17 Dec, 2018 1 commit
  27. 11 Dec, 2018 1 commit