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.
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.
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?
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?
It's indeed strange, can you add define('DEBUG_INSTALLER', true); right below the one that says <?php, try again and share a screenshot?
Also, which DBMS and WebServer are you running on?
Thanks!
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!
@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:
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.
@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.
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?
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?
Do you happen to know if that configuration can be changed on the fly?
Sure, just like that:
SET @@SQL_MODE = REPLACE(@@SQL_MODE, 'NO_ZERO_DATE', '');
> 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', '');
```
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!
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!
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.
> 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.
4 Try to install GNU social again (Unknown error). Detailed debug message will be shown with stack trace.
5 Please report it here.
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.
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.
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.
Pushed 9a515b9234, 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.
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*.
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.
> 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.
XRevan86
If I remember correctly, GNU Social had PHP7 issues - is this resolved in the nightly of this project?
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:
I don't recommend using nightly in production just yet. If you want to, please disable the ActivityPub plugin.
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?
It's indeed strange, can you add
define('DEBUG_INSTALLER', true);right below the one that says<?php, try again and share a screenshot?Also, which DBMS and WebServer are you running on?
Thanks!
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?
@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:
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.
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?
Sure, just like that:
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!
Well, the goal is to sort all this timestamp stuff out definitively.
And we don't use that zero date mess on PostgreSQL.
Hi [@murgero]. My GNU social nightly 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 xdebugand so on).2 Add following xdebug configuration in php.ini.
3 Insert
xdebug_print_function_stack('Your own message');to following onextlib/DB.php.4 Try to install GNU social again (
Unknown error). Detailed debug message will be shown with stack trace.5 Please report it here.
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.
I moved to use PSQL for this, which is working much better than MySQL - closing for now.
Pushed
9a515b9234, 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.
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
actorhas to be fetched. Thatactoris then added to GS'sprofiletable. We are able to tell apart which are remote and which are local due to ourusertable, and we're able to tell which are from Ostatus and which are from ActivityPub thanks to, respectively,ostatus_profileandactivitypub_profiletables.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_profileor inactivitypub_profileand never in both simultaneously, or worst - and this is what happens at the moment - duplicated in theprofiletable 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
nightlywithTheFreeNetworkModuleandOStatusPlugindisabled. 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.