Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Database Upgrade Failed from 1.2.3 to 1.2.5 #3300

Closed
jmcdomingues opened this issue Feb 26, 2020 · 37 comments
Closed

Database Upgrade Failed from 1.2.3 to 1.2.5 #3300

jmcdomingues opened this issue Feb 26, 2020 · 37 comments
Labels
bug Undesired behaviour

Comments

@jmcdomingues
Copy link

This is the error I've got after updating Cacti:

ALTER TABLE poller_output_realtime ROW_FORMAT=Dynamic, DROP PRIMARY KEY, ADD PRIMARY KEY (local_data_id, rrd_name, time, poller_id)

Process Log

2020/02/26 12:39:13 - INSTALL: always: Installation was started at 2020-02-26 12:38:55, completed at 2020-02-26 12:39:13
2020/02/26 12:39:13 - INSTALL: always: WARNING: One or more upgrades failed to install correctly
2020/02/26 12:39:13 - INSTALL: always: Finished UPGRADE Process for v1.2.9
2020/02/26 12:39:13 - INSTALL: always: Repairing Automation Rules
2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.2.3 (DB 1.2.3) to v1.2.5
2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.2.2 (DB 1.2.2) to v1.2.3
2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.2.1 (DB 1.2.1) to v1.2.2
2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.2.0 (DB 1.2.0) to v1.2.1
2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.1.37 (DB 1.1.37) to v1.2.0
2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.1.36 (DB 1.1.36) to v1.1.37
2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.1.35 (DB 1.1.35) to v1.1.36
2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.1.34 (DB 1.1.34) to v1.1.35
2020/02/26 12:39:12 - INSTALL: always: Upgrading from v1.1.31 (DB 1.1.31) to v1.1.34
2020/02/26 12:39:12 - INSTALL: always: Upgrading from v1.1.28 (DB 1.1.28) to v1.1.31
2020/02/26 12:39:12 - INSTALL: always: Upgrading from v1.1.26 (DB 1.1.26) to v1.1.28
2020/02/26 12:39:11 - INSTALL: always: Upgrading from v1.1.20 (DB 1.1.20) to v1.1.26
2020/02/26 12:39:11 - INSTALL: always: Upgrading from v1.1.17 (DB 1.1.17) to v1.1.20
2020/02/26 12:39:11 - INSTALL: always: Upgrading from v1.1.14 (DB 1.1.14) to v1.1.17
2020/02/26 12:39:11 - INSTALL: always: Upgrading from v1.1.11 (DB 1.1.11) to v1.1.14
2020/02/26 12:39:11 - INSTALL: always: Upgrading from v1.1.8 (DB 1.1.8) to v1.1.11
2020/02/26 12:39:11 - INSTALL: always: Upgrading from v1.1.7 (DB 1.1.7) to v1.1.8
2020/02/26 12:39:11 - INSTALL: always: Upgrading from v1.1.6 (DB 1.2.9 (DB: 1.1.6)) to v1.1.7
2020/02/26 12:39:11 - INSTALL: always: NOTE: Using temporary file for db cache: /tmp/cduziuKzh
2020/02/26 12:39:11 - INSTALL: always: Switched from to /tmp/cduziuKzh
2020/02/26 12:39:11 - INSTALL: always: Converting Table #116 'version'
2020/02/26 12:39:11 - INSTALL: always: Converting Table #115 'vdef_items'
2020/02/26 12:39:11 - INSTALL: always: Converting Table #114 'vdef'
2020/02/26 12:39:11 - INSTALL: always: Converting Table #113 'user_log'
2020/02/26 12:39:11 - INSTALL: always: Converting Table #112 'user_domains_ldap'

My server is:
CentOS 7

Thank you,
@bmfmancini
Copy link
Member

bmfmancini commented Feb 26, 2020 via email

@jmcdomingues
Copy link
Author

Do you have large_prefix =1 in your my.cnf
…
On Wed, Feb 26, 2020 at 8:08 AM jmcdomingues @.***> wrote: This is the error I've got after updating Cacti: ALTER TABLE poller_output_realtime ROW_FORMAT=Dynamic, DROP PRIMARY KEY, ADD PRIMARY KEY (local_data_id, rrd_name, time, poller_id) Process Log 2020/02/26 12:39:13 - INSTALL: always: Installation was started at 2020-02-26 12:38:55, completed at 2020-02-26 12:39:13 2020/02/26 12:39:13 - INSTALL: always: WARNING: One or more upgrades failed to install correctly 2020/02/26 12:39:13 - INSTALL: always: Finished UPGRADE Process for v1.2.9 2020/02/26 12:39:13 - INSTALL: always: Repairing Automation Rules 2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.2.3 (DB 1.2.3) to v1.2.5 2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.2.2 (DB 1.2.2) to v1.2.3 2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.2.1 (DB 1.2.1) to v1.2.2 2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.2.0 (DB 1.2.0) to v1.2.1 2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.1.37 (DB 1.1.37) to v1.2.0 2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.1.36 (DB 1.1.36) to v1.1.37 2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.1.35 (DB 1.1.35) to v1.1.36 2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.1.34 (DB 1.1.34) to v1.1.35 2020/02/26 12:39:12 - INSTALL: always: Upgrading from v1.1.31 (DB 1.1.31) to v1.1.34 2020/02/26 12:39:12 - INSTALL: always: Upgrading from v1.1.28 (DB 1.1.28) to v1.1.31 2020/02/26 12:39:12 - INSTALL: always: Upgrading from v1.1.26 (DB 1.1.26) to v1.1.28 2020/02/26 12:39:11 - INSTALL: always: Upgrading from v1.1.20 (DB 1.1.20) to v1.1.26 2020/02/26 12:39:11 - INSTALL: always: Upgrading from v1.1.17 (DB 1.1.17) to v1.1.20 2020/02/26 12:39:11 - INSTALL: always: Upgrading from v1.1.14 (DB 1.1.14) to v1.1.17 2020/02/26 12:39:11 - INSTALL: always: Upgrading from v1.1.11 (DB 1.1.11) to v1.1.14 2020/02/26 12:39:11 - INSTALL: always: Upgrading from v1.1.8 (DB 1.1.8) to v1.1.11 2020/02/26 12:39:11 - INSTALL: always: Upgrading from v1.1.7 (DB 1.1.7) to v1.1.8 2020/02/26 12:39:11 - INSTALL: always: Upgrading from v1.1.6 (DB 1.2.9 (DB: 1.1.6)) to v1.1.7 2020/02/26 12:39:11 - INSTALL: always: NOTE: Using temporary file for db cache: /tmp/cduziuKzh 2020/02/26 12:39:11 - INSTALL: always: Switched from to /tmp/cduziuKzh 2020/02/26 12:39:11 - INSTALL: always: Converting Table #116 <#116> 'version' 2020/02/26 12:39:11 - INSTALL: always: Converting Table #115 <#115> 'vdef_items' 2020/02/26 12:39:11 - INSTALL: always: Converting Table #114 <#114> 'vdef' 2020/02/26 12:39:11 - INSTALL: always: Converting Table #113 <#113> 'user_log' 2020/02/26 12:39:11 - INSTALL: always: Converting Table #112 <#112> 'user_domains_ldap' My server is: CentOS 7 Thank you, — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3300?email_source=notifications&email_token=ADGEXTBPDUXEYNI4H7R4W4TREZSVTA5CNFSM4K4E5IBKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IQOB54A>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGEXTAAY3JMJ5EUQTUXT5DREZSVTANCNFSM4K4E5IBA .
-- Thank you Sean Mancini,LBBIT Owner/Principal Engineer www.seanmancini.com “Companies spend millions of dollars on firewalls, encryption, and secure access devices, and it’s money wasted because none of these measures address the weakest link in the security chain.” – Kevin Mitnick

No. Do not even have that line.

@bmfmancini
Copy link
Member

Put this line in your my.cnf
innodb_large_prefix=1

and restart your mysql server

@jmcdomingues
Copy link
Author

Still the same!
Where can I find some logs in order to help you helping me! :)

@netniV
Copy link
Member

netniV commented Feb 26, 2020

Have you restart myself after the change ?

@jmcdomingues
Copy link
Author

Yes I have. Even rebooted the server.
I have this in /usr/share/cacti/log/cacti.log
"
2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.2.0 (DB 1.2.0) to v1.2.1
2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.2.1 (DB 1.2.1) to v1.2.2
2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.2.2 (DB 1.2.2) to v1.2.3
2020/02/26 12:39:13 - INSTALL: always: Upgrading from v1.2.3 (DB 1.2.3) to v1.2.5
2020/02/26 12:39:13 - CMDPHP ERROR: A DB Exec Failed!, Error: Specified key was too long; max key length is 767 bytes
2020/02/26 12:39:13 - CMDPHP SQL Backtrace: (/install/background.php[54]:Installer::beginInstall(), /lib/installer.php[3307]:Installer->install(), /lib/installer.php[2825]:Installer->upgradeDatabase(), /lib/installer.php[3206]:call_user_func(), upgrade_to_1_2_5(), /install/upgrades/1_2_5.php[59]:db_install_execute(), /install/functions.php[146]:db_execute_prepared())
2020/02/26 12:39:13 - INSTALL: always: Repairing Automation Rules
2020/02/26 12:39:13 - INSTALL: always: Finished UPGRADE Process for v1.2.9
2020/02/26 12:39:13 - INSTALL: always: WARNING: One or more upgrades failed to install correctly
"

@jmcdomingues
Copy link
Author

Do I have to rerun something?

@bmfmancini
Copy link
Member

bmfmancini commented Feb 26, 2020 via email

@jmcdomingues
Copy link
Author

jmcdomingues commented Feb 26, 2020 •
edited

here:
/etc/my.cnf

"
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
.# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
.# Settings user and group are ignored when systemd is used.
.# If you need to run mysqld under a different user or group,
.# customize your systemd unit file for mariadb according to the
.# instructions in http://fedoraproject.org/wiki/Systemd
max_heap_table_size = 1169M
max_allowed_packet = 16777216
tmp_table_size = 64M
join_buffer_size = 64M
innodb_file_per_table = ON
innodb_buffer_pool_size = 5844M
innodb_doublewrite = OFF
innodb_additional_mem_pool_size = 80M
innodb_flush_log_at_trx_commit = 2
innodb_large_prefix=1 <<<<=================================================

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid

.#
.# include all files from the config directory
.#
!includedir /etc/my.cnf.d
"

@bmfmancini
Copy link
Member

change
innodb_large_prefix=1
to
innodb_large_prefix = 1

@jmcdomingues
Copy link
Author

Still not working.
Did reboot server and accessed with Firefox in private mode, just to be sure...

@bmfmancini
Copy link
Member

bmfmancini commented Feb 26, 2020 via email

@jmcdomingues
Copy link
Author

"Try to run the alter command manually"

I do not have experience with SQL tables manipulation.
Can you tell me the procedure, please?
Thanks,

@bmfmancini
Copy link
Member

Actually I see you are missing some things from your my.cnf

You need to be using the barracuda file system
enter the following variables into your my.cnf

innodb_file_format = Barracuda

save the file
restart the mysql service

@jmcdomingues
Copy link
Author

Still not working! :(

@jmcdomingues
Copy link
Author

jmcdomingues commented Feb 26, 2020 •
edited

Now my file looks like this:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
.# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
.# Settings user and group are ignored when systemd is used.
.# If you need to run mysqld under a different user or group,
.# customize your systemd unit file for mariadb according to the
.# instructions in http://fedoraproject.org/wiki/Systemd
max_heap_table_size = 1169M
max_allowed_packet = 16777216
tmp_table_size = 64M
join_buffer_size = 64M
innodb_file_per_table = ON
innodb_buffer_pool_size = 5844M
innodb_doublewrite = OFF
innodb_additional_mem_pool_size = 80M
innodb_flush_log_at_trx_commit = 2
innodb_large_prefix = 1
innodb_file_format = Barracuda

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid
.#
.# include all files from the config directory
.#
!includedir /etc/my.cnf.d

@bmfmancini
Copy link
Member

what error do you get now ?

@jmcdomingues
Copy link
Author

Today I have this:
"
Process Log
--- NO LOG FOUND ---
"
but I think this is because log has rotated.
Yesterday I just kept having the same error.
Should I do any command in order to try reinstallation?

@jmcdomingues
Copy link
Author

Looking into yesterday's logs, this is what I have:
"
...
2020/02/26 12:39:00 - INSTALL: always: Converting Table #42 'data_template_rrd'
2020/02/26 12:39:01 - INSTALL: always: Converting Table #43 'external_links'
2020/02/26 12:39:01 - INSTALL: always: Converting Table #44 'graph_local'
2020/02/26 12:39:01 - INSTALL: always: Converting Table #45 'graph_template_input'
2020/02/26 12:39:01 - INSTALL: always: Converting Table #46 'graph_template_input_defs'
2020/02/26 12:39:01 - INSTALL: always: Converting Table #47 'graph_templates'
2020/02/26 12:39:01 - INSTALL: always: Converting Table #48 'graph_templates_gprint'
2020/02/26 12:39:01 - INSTALL: always: Converting Table #49 'graph_templates_graph'
2020/02/26 12:39:02 - ERROR PHP NOTICE: Undefined index: processes in file: /usr/share/cacti/poller.php on line: 224
2020/02/26 12:39:02 - CMDPHP PHP ERROR NOTICE Backtrace: (/poller.php[224]:CactiErrorHandler())
2020/02/26 12:39:02 - CMDPHP ERROR: A DB Row Failed!, Error: Unknown column 'deleted' in 'where clause'
2020/02/26 12:39:02 - CMDPHP SQL Backtrace: (/poller.php[376]:db_fetch_assoc_prepared(), /lib/database.php[487]:db_execute_prepared())
2020/02/26 12:39:02 - ERROR PHP WARNING: array_merge(): Argument #2 is not an array in file: /usr/share/cacti/poller.php on line: 376
2020/02/26 12:39:02 - CMDPHP PHP ERROR WARNING Backtrace: (/poller.php[376]:array_merge(), CactiErrorHandler())
2020/02/26 12:39:02 - ERROR PHP WARNING: Invalid argument supplied for foreach() in file: /usr/share/cacti/poller.php on line: 586
2020/02/26 12:39:02 - CMDPHP PHP ERROR WARNING Backtrace: (/poller.php[586]:CactiErrorHandler())
2020/02/26 12:39:02 - SYSTEM STATS: Time:0.0157 Method:cmd.php Processes:1 Threads:0 Hosts:-1 HostsPerProcess:-1 DataSources:839 RRDsProcessed:0
2020/02/26 12:39:02 - CMDPHP ERROR: A DB Row Failed!, Error: Unknown column 'sync_interval' in 'where clause'
2020/02/26 12:39:02 - CMDPHP SQL Backtrace: (/poller.php[792]:poller_replicate_check(), /poller.php[853]:db_fetch_assoc(), /lib/database.php[473]:db_fetch_assoc_prepared(), /lib/database.php[487]:db_execute_prepared())
2020/02/26 12:39:02 - ERROR PHP WARNING: Invalid argument supplied for foreach() in file: /usr/share/cacti/poller.php on line: 855
2020/02/26 12:39:02 - CMDPHP PHP ERROR WARNING Backtrace: (/poller.php[792]:poller_replicate_check(), /poller.php[855]:CactiErrorHandler())
2020/02/26 12:39:02 - INSTALL: always: Converting Table #50 'graph_templates_item'
2020/02/26 12:39:02 - CMDPHP ERROR: A DB Row Failed!, Error: Table 'cacti.data_debug' doesn't exist
2020/02/26 12:39:02 - CMDPHP SQL Backtrace: (/poller.php[796]:dsdebug_poller_bottom(), /lib/dsdebug.php[148]:db_fetch_assoc(), /lib/database.php[473]:db_fetch_assoc_prepared(), /lib/database.php[487]:db_execute_prepared())
2020/02/26 12:39:02 - CMDPHP ERROR: A DB Row Failed!, Error: Unknown column 'deleted' in 'where clause'
2020/02/26 12:39:02 - CMDPHP SQL Backtrace: (/poller_maintenance.php[146]:api_device_purge_deleted_devices(), /lib/api_device.php[111]:db_fetch_assoc_prepared(), /lib/database.php[487]:db_execute_prepared())
2020/02/26 12:39:02 - INSTALL: always: Converting Table #51 'graph_tree'
2020/02/26 12:39:03 - INSTALL: always: Converting Table #52 'graph_tree_items'
2020/02/26 12:39:03 - INSTALL: always: Converting Table #53 'host'
2020/02/26 12:39:03 - INSTALL: always: Converting Table #54 'host_graph'
...
"

@netniV
Copy link
Member

netniV commented Feb 28, 2020

OK, you can ignore the poller errors. This is because you have a whole bunch of table converts going on, before the database upgrade has been done. As a result, your database is still at its pre-1.2.x state and yet 1.2.x code is trying to run.

It's a known issue if you don't stop cron before performing an upgrade. But you can ignore that for now.

@netniV netniV added the bug Undesired behaviour label Feb 28, 2020
@jmcdomingues
Copy link
Author

So, can I do something for now?

@netniV
Copy link
Member

netniV commented Feb 29, 2020

it looked like that the install was still going, it was converting tables?

@jmcdomingues
Copy link
Author

My file install-general.log has this final lines:
"
...
[2020-02-26 12:39:13] [ global always ] Upgrading from v1.2.0 (DB 1.2.0) to v1.2.1
[2020-02-26 12:39:13] [ global always ] Upgrading from v1.2.1 (DB 1.2.1) to v1.2.2
[2020-02-26 12:39:13] [ global always ] Upgrading from v1.2.2 (DB 1.2.2) to v1.2.3
[2020-02-26 12:39:13] [ global always ] Upgrading from v1.2.3 (DB 1.2.3) to v1.2.5
[2020-02-26 12:39:13] [ global always ] Repairing Automation Rules
[2020-02-26 12:39:13] [ global always ] Finished UPGRADE Process for v1.2.9
[2020-02-26 12:39:13] [ global always ] WARNING: One or more upgrades failed to install correctly
[2020-02-26 12:39:13] [ global always ] Installation was started at 2020-02-26 12:38:55, completed at 2020-02-26 12:39:13
"

@netniV
Copy link
Member

netniV commented Mar 3, 2020

Search the past issues for innodb_large_prefix, I think that will solve your problem.

@jmcdomingues
Copy link
Author

I've found one which it is recommended to run:

MariaDB [cacti]> alter table host_snmp_cache row_format=dynamic;
Query OK, 11150 rows affected (1.71 sec)
Records: 11150 Duplicates: 0 Warnings: 0

but still with the same error.

Your Cacti Server v1.2.9 has been installed/updated with errors

@bmfmancini
Copy link
Member

bmfmancini commented Mar 3, 2020 via email

@netniV
Copy link
Member

netniV commented Mar 4, 2020

There is row format and there is also the updating of the mysql configuration files. You appear to have only done the row format, double check you have done the other changes too.

@jmcdomingues
Copy link
Author

jmcdomingues commented Mar 4, 2020 •
edited

Here is my my.cnf

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
.# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
.# Settings user and group are ignored when systemd is used.
.# If you need to run mysqld under a different user or group,
.# customize your systemd unit file for mariadb according to the
.# instructions in http://fedoraproject.org/wiki/Systemd
max_heap_table_size = 1169M
max_allowed_packet = 16777216
tmp_table_size = 64M
join_buffer_size = 64M
innodb_file_per_table = ON
innodb_buffer_pool_size = 5844M
innodb_doublewrite = OFF
innodb_additional_mem_pool_size = 80M
innodb_flush_log_at_trx_commit = 2
innodb_large_prefix = 1
innodb_file_format = Barracuda

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid

.#
.# include all files from the config directory
.#
!includedir /etc/my.cnf.d

Using the recommended entries suggested earlier in this thread.
Is anything else I should change?

@netniV
Copy link
Member

netniV commented Mar 4, 2020

Have you verified that the above configuration is actually active within MySQL? We have had instances where people have made configuration changes that haven't been active within MySQL for one reason or another (usually MySQL dislikes something that's being set).

@jmcdomingues
Copy link
Author

As far as I can see, yes it is.
But can you tell me an effective way to check this?
I'm kinda new to MYSQL, so if you can elaborate a little more in your answers I will be much obliged.
Thank you.

@bmfmancini
Copy link
Member

bmfmancini commented Mar 4, 2020 via email

@jmcdomingues
Copy link
Author

jmcdomingues commented Mar 4, 2020 •
edited

Thank you Sean.
I had already tried "/usr/libexec/mysqld --verbose --help | grep -A 1 "Default options"", and got
200304 17:14:22 [Note] Plugin 'FEEDBACK' is disabled.
Default options are read from the following files in the given order:
/etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf

and I only have /etc/my.cnf.

for the %prefix%
mysql -u cactiuser -p ;
...
MariaDB [(none)]> show variables LIKE '%prefix%';
+---------------------+-------+
| Variable_name | Value |
+---------------------+-------+
| innodb_large_prefix | ON |
+---------------------+-------+
1 row in set (0.01 sec)

So it is ok, I think!

@jmcdomingues
Copy link
Author

Can you give me more ideas, please?
Still not working.
Thank you,

@netniV
Copy link
Member

netniV commented Mar 6, 2020

I am currently updating the installer upgrade routines so that every step is logged not just certain ones. In the mean time, can you email me a copy of your install-complete.log which should have more information.

@cigamit
Copy link
Member

cigamit commented Mar 8, 2020

Please pull the 1.2.x branch and then copy over the current branch. Then, goto the MySQL prompt, run the following command:

DELETE FROM settings WHERE name like 'install%';

After that, try to upgrade again.

@jmcdomingues
Copy link
Author

jmcdomingues commented Mar 9, 2020 via email •
edited

@jmcdomingues
Copy link
Author

DELETE FROM settings WHERE name like 'install%';

Thank you Jimmy, that solved the issue. Before being more radical I just gave the command you suggested and restarted the process. Made some of the recommended adjustments and restarted the process, and BAM! It worked with no more issues! :)
Thank you so much!

@github-actions github-actions bot locked and limited conversation to collaborators Jun 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
bug Undesired behaviour
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@cigamit @netniV @bmfmancini @jmcdomingues