Two new features

Repology links - each port now has a link to repology.org. See issue 148 for details.

Ports I maintain report - port maintainers can now subscribe to a daily report of commits to the ports they maintain. See Watch ports I maintain at Report Subscriptions. Details at issue 138

Search FreshPorts using Google

not searching src

The FreshPorts Search

Include deleted ports

Case sensitive search

Sort by:

Include /src tree

Output format:
HTML
Plain Text

Maximum Effort

Minimal output

Branch:

Notes

Case sensitivity is ignored for "sounds like" and output is ordered by the soundex.

When searching on 'Message ID', the type of match is ignored.

When searching on 'Commit Message' only 'containing' is used.

When searching by 'Under a pathname', your path must start with something like /ports/, /doc/, or /src/. All
commits under that point will be returned. The selected match type is ignored and defaults to 'Starts with'.

Searching for 'sounds like' is only valid for Committer, Maintainer, Package Name, and Port Name.

Update to 11.66
Changes since last update of this port:
Version 11.66
- QS_ClientIpFromHeader supports pseudo IP by creating a hash
of a HTTP request header's value if the header name is prefixed
by '#', e.g. #Authorization to use the HTTP basic auth header.
It's also possible to use the client's SSL client certificate's
subject and issuer DN if you specify #SSL_CLIENT_S_DN instead
of a real HTTP header name.
Note: Does not work for IP geolocation.
Version 11.65

MFH: r534263
databases/mysql80-{client, server}: Update to latest release 8.0.20
- Performance: Certain queries against tables with spatial indexes were not
performed as efficiently following an upgrade from MySQL 5.7 to MySQL 8.0.
- NDB Cluster: NDB defines one SPJ worker per node owning a primary partition of
the root table. If this table used read from any replica, DBTC put all SPJ
workers in the same DBSPJ instance, which effe
- NDB Cluster: Executing the SHOW command using an ndb_mgm client binary from
NDB 8.0.16 or earlier to access a management node running NDB 8.0.17 or later
produced the error message Unknown field: is_s
- On EL7 and EL8, CMake configuration was adjusted to look for GCC 9 before GCC
8. Because libmysqlclient ships with MySQL distributions, client applications
built against libmysqlclient on those platfo
- The max_length_for_sort_data system variable is now deprecated due to
optimizer changes that make it obsolete and of no effect.
More Infos: https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-20.html
Special thanks to: fluffy
Security: 21d59ea3-8559-11ea-a5e2-d4c9ef517024 (MySQL - Server)
Security: 622b5c47-855b-11ea-a5e2-d4c9ef517024 (MySQL - Client)
Sponsored by: Netzkommune GmbH
Approved by: ports-secteam (with hat)

databases/mysql80-{client, server}: Update to latest release 8.0.20
- Performance: Certain queries against tables with spatial indexes were not
performed as efficiently following an upgrade from MySQL 5.7 to MySQL 8.0.
- NDB Cluster: NDB defines one SPJ worker per node owning a primary partition of
the root table. If this table used read from any replica, DBTC put all SPJ
workers in the same DBSPJ instance, which effe
- NDB Cluster: Executing the SHOW command using an ndb_mgm client binary from
NDB 8.0.16 or earlier to access a management node running NDB 8.0.17 or later
produced the error message Unknown field: is_s
- On EL7 and EL8, CMake configuration was adjusted to look for GCC 9 before GCC
8. Because libmysqlclient ships with MySQL distributions, client applications
built against libmysqlclient on those platfo
- The max_length_for_sort_data system variable is now deprecated due to
optimizer changes that make it obsolete and of no effect.
More Infos: https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-20.html
Special thanks to: fluffy
MFH: 2020Q2
Security: 21d59ea3-8559-11ea-a5e2-d4c9ef517024 (MySQL - Server)
Security: 622b5c47-855b-11ea-a5e2-d4c9ef517024 (MySQL - Client)
Sponsored by: Netzkommune GmbH

MFH: r533416
databases/mysq56-{client, server}: Update to latest release 5.7.30
Bugs Fixed:
- InnoDB: The row_upd_clust_rec_by_insert function, which marks a clustered
index record as deleted and inserts an updated version of the record into the
clustered index, passed an incorrect n_ext value (the total number of external
fields) to lower level functions, causing an assertion failure.
- InnoDB: An operation performed with the innodb_buffer_pool_evict debug
variable set to uncompressed caused an assertion failure.
- InnoDB: An add column operation caused an assertion failure. The failure was
due to a dangling pointer.
- nnoDB: Updating certain InnoDB system variables that take string values raised
invalid read errors during Valgrind testing.
- InnoDB: An insert statement on a table with a spatial index raised a record
type mismatch assertion due to a tuple corruption.
- InnoDB: A function that calculates undo log record size could calculate an
incorrect length value in the case of a corrupted undo log record, resulting in
a malloc failure. Assertion code was added to detect incorrect calculations.
- Replication: While an SQL statement was in the process of being rewritten for
the binary log so that sensitive information did not appear in plain text, if a
SHOW PROCESSLIST statement was used to inspect the query, the query could become
corrupted when it was written to the binary log, causing replication to stop.
The process of rewriting the query is now kept private, and the query thread is
updated only when rewriting is complete.
- Replication: When a GRANT or REVOKE statement is only partially executed, an
incident event is logged in the binary log, which makes the replication slave's
applier thread stop so that the slave can be reconciled manually with the
master. Previously, if a failed GRANT or REVOKE statement was the first
statement executed in the session, no GTID was applied to the incident event
(because the cache manager did not yet exist for the session), causing an error
on the replication slave. Also, no incident event was logged in the situation
where a GRANT statement created a user but then failed because the privileges
had been specified incorrectly, again causing an error on the replication slave.
Both these issues have now been fixed.
- Replication: When a replication slave has a generated column that the master
does not have in that table, with a secondary index on the generated column, the
generated expression should be evaluated and the value stored by the storage
engine in the secondary index. When row-based binary logging is in use, the
replication slave assigns default values to any fields that are not in the
master's definition of the table. In the case of a generated column, which does
not have a default value, the slave was previously assigning a null or a zero
value to the column. This value was then stored by the storage engine in the
secondary index, causing both the table and the index to become corrupted. To
fix this issue, generated columns in a table on a replication slave are now
re-evaluated before the values are sent to the storage engine.
- Replication: In the event of an unplanned disconnection of a replication slave
from the master, the reference to the master's dump thread might not be removed
from the list of registered slaves, in which case statements that accessed the
list of slaves would fail. The issue has now been fixed.
- Replication: With the settings binlog_format=MIXED,
tx_isolation=READ-COMMITTED, and binlog_row_image=FULL, an INSERT ... SELECT
query involving a transactional storage engine omitted any columns with a null
value from the row image written to the binary log. This happened because when
processing INSERT ... SELECT statements, the columns were marked for inserts
before the binary logging format was selected. The issue has now been fixed.
Full Changelog: https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-30.html
Security: 21d59ea3-8559-11ea-a5e2-d4c9ef517024 (MySQL - Server)
Security: 622b5c47-855b-11ea-a5e2-d4c9ef517024 (MySQL - Client)
Sponsored by: Netzkommune GmbH
Approved by: ports-secteam (joneum)

databases/mysq56-{client, server}: Update to latest release 5.7.30
Bugs Fixed:
- InnoDB: The row_upd_clust_rec_by_insert function, which marks a clustered
index record as deleted and inserts an updated version of the record into the
clustered index, passed an incorrect n_ext value (the total number of external
fields) to lower level functions, causing an assertion failure.
- InnoDB: An operation performed with the innodb_buffer_pool_evict debug
variable set to uncompressed caused an assertion failure.
- InnoDB: An add column operation caused an assertion failure. The failure was
due to a dangling pointer.
- nnoDB: Updating certain InnoDB system variables that take string values raised
invalid read errors during Valgrind testing.
- InnoDB: An insert statement on a table with a spatial index raised a record
type mismatch assertion due to a tuple corruption.
- InnoDB: A function that calculates undo log record size could calculate an
incorrect length value in the case of a corrupted undo log record, resulting in
a malloc failure. Assertion code was added to detect incorrect calculations.
- Replication: While an SQL statement was in the process of being rewritten for
the binary log so that sensitive information did not appear in plain text, if a
SHOW PROCESSLIST statement was used to inspect the query, the query could become
corrupted when it was written to the binary log, causing replication to stop.
The process of rewriting the query is now kept private, and the query thread is
updated only when rewriting is complete.
- Replication: When a GRANT or REVOKE statement is only partially executed, an
incident event is logged in the binary log, which makes the replication slave's
applier thread stop so that the slave can be reconciled manually with the
master. Previously, if a failed GRANT or REVOKE statement was the first
statement executed in the session, no GTID was applied to the incident event
(because the cache manager did not yet exist for the session), causing an error
on the replication slave. Also, no incident event was logged in the situation
where a GRANT statement created a user but then failed because the privileges
had been specified incorrectly, again causing an error on the replication slave.
Both these issues have now been fixed.
- Replication: When a replication slave has a generated column that the master
does not have in that table, with a secondary index on the generated column, the
generated expression should be evaluated and the value stored by the storage
engine in the secondary index. When row-based binary logging is in use, the
replication slave assigns default values to any fields that are not in the
master's definition of the table. In the case of a generated column, which does
not have a default value, the slave was previously assigning a null or a zero
value to the column. This value was then stored by the storage engine in the
secondary index, causing both the table and the index to become corrupted. To
fix this issue, generated columns in a table on a replication slave are now
re-evaluated before the values are sent to the storage engine.
- Replication: In the event of an unplanned disconnection of a replication slave
from the master, the reference to the master's dump thread might not be removed
from the list of registered slaves, in which case statements that accessed the
list of slaves would fail. The issue has now been fixed.
- Replication: With the settings binlog_format=MIXED,
tx_isolation=READ-COMMITTED, and binlog_row_image=FULL, an INSERT ... SELECT
query involving a transactional storage engine omitted any columns with a null
value from the row image written to the binary log. This happened because when
processing INSERT ... SELECT statements, the columns were marked for inserts
before the binary logging format was selected. The issue has now been fixed.
Full Changelog: https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-30.html
MFH: 2020Q2
Security: 21d59ea3-8559-11ea-a5e2-d4c9ef517024 (MySQL - Server)
Security: 622b5c47-855b-11ea-a5e2-d4c9ef517024 (MySQL - Client)
Sponsored by: Netzkommune GmbH

MFH: r533270
databases/mysql56-{client, server}: Update to latest release 5.6.48
Bugfix:
- InnoDB: A tablespace import operation that failed due to the source and
destination tables being defined with different DATA DIRECTORY clauses reported
an insufficiently descriptive schema mismatch error. Moreover, if a .cfg file
was not present, the same operation would raise an assertion failure. A more
informative error message is now reported in both cases before the import
operation is terminated due to the data directory mismatch.
- InnoDB: Updating certain InnoDB system variables that take string values
raised invalid read errors during Valgrind testing.
- Replication: In the event of an unplanned disconnection of a replication slave
from the master, the reference to the master's dump thread might not be removed
from the list of registered slaves, in which case statements that accessed the
list of slaves would fail. The issue has now been fixed
- Replication: With the settings binlog_format=MIXED,
tx_isolation=READ-COMMITTED, and binlog_row_image=FULL, an INSERT ... SELECT
query involving a transactional storage engine omitted any columns with a null
value from the row image written to the binary log. This happened because when
processing INSERT ... SELECT statements, the columns were marked for inserts
before the binary logging format was selected. The issue has now been fixed.
More Infos: https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-48.html
Security: 21d59ea3-8559-11ea-a5e2-d4c9ef517024 (MySQL - Server)
Security: 622b5c47-855b-11ea-a5e2-d4c9ef517024 (MySQL - Client)
Sponsored by: Netzkommune GmbH
Approved by: ports-secteam (joneum)

databases/mysql56-{client, server}: Update to latest release 5.6.48
Bugfix:
- InnoDB: A tablespace import operation that failed due to the source and
destination tables being defined with different DATA DIRECTORY clauses reported
an insufficiently descriptive schema mismatch error. Moreover, if a .cfg file
was not present, the same operation would raise an assertion failure. A more
informative error message is now reported in both cases before the import
operation is terminated due to the data directory mismatch.
- InnoDB: Updating certain InnoDB system variables that take string values
raised invalid read errors during Valgrind testing.
- Replication: In the event of an unplanned disconnection of a replication slave
from the master, the reference to the master's dump thread might not be removed
from the list of registered slaves, in which case statements that accessed the
list of slaves would fail. The issue has now been fixed
- Replication: With the settings binlog_format=MIXED,
tx_isolation=READ-COMMITTED, and binlog_row_image=FULL, an INSERT ... SELECT
query involving a transactional storage engine omitted any columns with a null
value from the row image written to the binary log. This happened because when
processing INSERT ... SELECT statements, the columns were marked for inserts
before the binary logging format was selected. The issue has now been fixed.
More Infos: https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-48.html
MFH: 2020Q2
Security: 21d59ea3-8559-11ea-a5e2-d4c9ef517024 (MySQL - Server)
Security: 622b5c47-855b-11ea-a5e2-d4c9ef517024 (MySQL - Client)
Sponsored by: Netzkommune GmbH