Página inicial Explorar Ajuda
Entrar
someonewithpc
/
gnusocial-issues
Observar 1
Favorito 0
Fork 0
Arquivos Issues 0 Pull Requests 0 Wiki
Branch: master
Branches Tags
gnusocial-is...
/
issues
/
notabug.org
/
160

160 7.8 KB
Link permanente Histórico Raw

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697 
  1. ---
    2. 

  2. title: Install failing on php 7
    3. 

  3. author: notabug.org/murgero
    4. 

  4. time: Fri, 26 Jun 2020 18:01:10 UTC
    5. 

  5. status: closed
    6. 

  6. ---
    7. 

  7. 

  8. author: notabug.org
    9. 

  9. time: Fri, 26 Jun 2020 18:01:10 UTC
    10. 

  10. content: -----
    11. 

  11. If I remember correctly, GNU Social had PHP7 issues - is this resolved in the nightly of this project?
    12. 

  12. -----
    13. 

  13. 

  14. author: notabug.org
    15. 

  15. time: Fri, 26 Jun 2020 18:41:13 UTC
    16. 

  16. content: -----
    17. 

  17. It is, we've in fact dropped support for PHP5.6.x. Being 7.0.0 the minimum PHP version for the 1.20.x branch. For master and nightly it is recommended that you run PHP 7.3+ and MariaDB 10.3+. Either nginx, apache2 and lighttpd should work fine as webserver with any release. Our changelog is available here: https://notabug.org/diogo/gnu-social/src/nightly/CHANGELOG.md Please note, about the branches: - 1.20.x is the latest release (v1.20.10) - master is fairly stable and acceptable to be used in production - nightly is force pushed somewhat frequently and is intended for devs - experimental is for my own testing I don't recommend using nightly in production just yet. If you want to, please disable the ActivityPub plugin.
    18. 

  18. -----
    19. 

  19. 

  20. author: notabug.org
    21. 

  21. time: Fri, 26 Jun 2020 19:10:08 UTC
    22. 

  22. content: -----
    23. 

  23. Hmm this is strange - I am on php 7.3, but I cannot install due to an "Unknown error"? This is the same on master or nightly, am I just doing something wrong?
    24. 

  24. -----
    25. 

  25. 

  26. author: notabug.org
    27. 

  27. time: Fri, 26 Jun 2020 19:49:19 UTC
    28. 

  28. content: -----
    29. 

  29. It's indeed strange, can you add `define('DEBUG_INSTALLER', true);` right below the one that says [`<?php`](https://notabug.org/diogo/gnu-social/src/nightly/public/install.php#L1), try again and share a screenshot? Also, which DBMS and WebServer are you running on? Thanks!
    30. 

  30. -----
    31. 

  31. 

  32. author: notabug.org
    33. 

  33. time: Fri, 26 Jun 2020 20:01:19 UTC
    34. 

  34. content: -----
    35. 

  35. Apache, and MariaDB/MySQL - I think I've seen this issue before, there is a configuration I have to change in MySQL isn't there?
    36. 

  36. -----
    37. 

  37. 

  38. author: notabug.org
    39. 

  39. time: Fri, 26 Jun 2020 20:50:32 UTC
    40. 

  40. content: -----
    41. 

  41. @murgero, for now GNU social needs zero dates, which are by default disabled in Oracle MySQL 8.0+. So if that's the version you are using, then try adding this to the configuration file: ```ini sql_mode = ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION ``` This is equivalent to the current defaults, except without ```NO_ZERO_DATE```. Everything else is fine. But maybe it is not the reason for the failure. You can try copying these commands into CLI and observing the error there.
    42. 

  42. -----
    43. 

  43. 

  44. author: notabug.org
    45. 

  45. time: Fri, 26 Jun 2020 20:53:16 UTC
    46. 

  46. content: -----
    47. 

  47. Yes! I remember now, I think the NO_ZERO_DATE is the issue - I had a similar problem with a different PHP script about a year ago. Do you happen to know if that configuration can be changed on the fly?
    48. 

  48. -----
    49. 

  49. 

  50. author: notabug.org
    51. 

  51. time: Fri, 26 Jun 2020 20:57:47 UTC
    52. 

  52. content: -----
    53. 

  53. > Do you happen to know if that configuration can be changed on the fly? Sure, just like that: ```sql SET @@SQL_MODE = REPLACE(@@SQL_MODE, 'NO_ZERO_DATE', ''); ```
    54. 

  54. -----
    55. 

  55. 

  56. author: notabug.org
    57. 

  57. time: Fri, 26 Jun 2020 21:07:00 UTC
    58. 

  58. content: -----
    59. 

  59. How hard would it be to streamline this into each query instead? It can be set per session as well and that may help a lot of admins in the future. Also, thank you for the snippet!
    60. 

  60. -----
    61. 

  61. 

  62. author: notabug.org
    63. 

  63. time: Fri, 26 Jun 2020 22:06:58 UTC
    64. 

  64. content: -----
    65. 

  65. > How hard would it be to streamline this into each query instead? It can be set per session as well and that may help a lot of admins in the future. Well, the goal is to sort all this timestamp stuff out definitively. And we don't use that zero date mess on PostgreSQL.
    66. 

  66. -----
    67. 

  67. 

  68. author: notabug.org
    69. 

  69. time: Sun, 28 Jun 2020 02:57:34 UTC
    70. 

  70. content: -----
    71. 

  71. Hi [@murgero]. [My GNU social nightly](https://social.senooken.jp/senooken) is running on PHP 7.3 with MySQL and Apache. I encountered same problem in my past, but no problem now (I forgot details). So I think this is PHP configuration problem. If it is possible, please try following debug process. 1 Install xdebug (`pecl install xdebug` and so on). 2 Add following xdebug configuration in php.ini. ``` zend_extension = xdebug xdebug.default_enable = true xdebug.force_display_errors = 1 xdebug.force_error_reporting = 1 xdebug.collect_params = 4 ``` 3 Insert `xdebug_print_function_stack('Your own message');` to following on `extlib/DB.php`. ``` function __construct($code = DB_ERROR, $mode = PEAR_ERROR_RETURN, $level = E_USER_NOTICE, $debuginfo = null) { xdebug_print_function_stack('Your own message'); // Insert here if (is_int($code)) { parent::__construct('DB Error: ' . DB::errorMessage($code), $code, $mode, $level, $debuginfo); } else { parent::__construct("DB Error: $code", DB_ERROR, $mode, $level, $debuginfo); } } ``` 4 Try to install GNU social again (`Unknown error`). Detailed debug message will be shown with stack trace. 5 Please report it here.
    72. 

  72. -----
    73. 

  73. 

  74. author: notabug.org
    75. 

  75. time: Mon, 29 Jun 2020 01:46:47 UTC
    76. 

  76. content: -----
    77. 

  77. How stable is the ActivityPub code ATM? in any of the branches? I plan on packaging this app for https://cloudron.io and wanted to know if I should disable that by default.
    78. 

  78. -----
    79. 

  79. 

  80. author: notabug.org
    81. 

  81. time: Mon, 29 Jun 2020 04:35:18 UTC
    82. 

  82. content: -----
    83. 

  83. I moved to use PSQL for this, which is working much better than MySQL - closing for now.
    84. 

  84. -----
    85. 

  85. 

  86. author: notabug.org
    87. 

  87. time: Mon, 29 Jun 2020 11:04:28 UTC
    88. 

  88. content: -----
    89. 

  89. Pushed 9a515b9234eeb2e500e88899fb31f64535b618cc, which removes the usage of "zero dates" from GNU social for good. I also want to point out that because of the nature of how we make connections to the database (ephemeral), PostgreSQL is not doing an efficient job. It won't make a noticeable difference for instances that don't receive many connections (or have them capped, like the default 100 simultaneous connections maximum), but generally I'd recommend wrapping it in *pgbouncer*.
    90. 

  90. -----
    91. 

  91. 

  92. author: notabug.org
    93. 

  93. time: Mon, 29 Jun 2020 23:50:14 UTC
    94. 

  94. content: -----
    95. 

  95. > How stable is the ActivityPub code ATM? in any of the branches? I plan on packaging this app for https://cloudron.io and wanted to know if I should disable that by default. The only branch with ActivityPub (and TheFreeNetwork module) is `nightly`. ActivityPub at the moment isn't perfect but works; TheFreeNetwork module isn't ready although making progress. When you receive an activity via federation with a remote instance, either with OStatus or ActivityPub, the remote `actor` has to be fetched. That `actor` is then added to GS's `profile` table. We are able to tell apart which are remote and which are local due to our `user` table, and we're able to tell which are from Ostatus and which are from ActivityPub thanks to, respectively, `ostatus_profile` and `activitypub_profile` tables. Hence, TheFreeNetwork module is needed to ensure only one federation protocol is used per remote Actor (i.e. a remote actor either is on `ostatus_profile` or in `activitypub_profile` and never in both simultaneously, or worst - and this is what happens at the moment - duplicated in the `profile` table due to being fetched by both plugins in different moments). Furthermore, ActivityPubPlugin has to support everything OStatus does, otherwise TFNM would be alternating both protocols whenever an only-OStatus-supported activity is received or has to be sent. Neither goal was fully completed yet. Therefore, if you really want ActivityPub at every cost, you must use `nightly` with `TheFreeNetworkModule` and `OStatusPlugin` disabled. That will lead to an ActivityPub enabled but less-featured GNU social. On the bright side, when we finish both things, you should be able to upgrade with no struggles. Having both ActivityPub and OStatus enabled _now_ will lead to a really ugly database. My recommendation is to **use master** (or nightly with both TFNM and ActivityPub disabled) and **wait a little bit longer**, I know we've been failing every self-proposed ETA, but I think we're finally close of getting this done for once.
    96. 

  96. -----
    97. 

  97.