The upstream configure script has been updated so this will port will now
correctly link against the ports version of OpenSSL if requested.
The --with-perl option no longer needs an argument, it uses the perl binary
to find the correct paths.
The --with-tcl option takes a TCL_LIBDIR argument to specify exactly which
TCL version to use if multiple are installed.
PR: 236881
Submitted by: caf@bitchx.org
- Update to port version 2.10.6
- Clean up mirror sites
- switch to OPTION_USES framework
- Fix PERL build option by replacing ${PERL_VERSION} with ${PERL_VER} in the path
that is passed to --with-perl
- Minor changes to satisfy portlint
PR: 236709
Submitted by: caf@bitchx.org
In file included from src/access.cpp:12:
In file included from include/service.h:15:
In file included from include/services.h:22:
In file included from /usr/include/c++/v1/stdexcept:46:
In file included from /usr/include/c++/v1/exception:81:
In file included from /usr/include/c++/v1/cstddef:38:
include/version:1:1: error: expected unqualified-id
<U+007F>ELF<U+0002><U+0001><U+0001> <U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0002><U+0000>><U+0000><U+0001><U+0000><U+0000><U+0000><U+0000>P <U+0000><U+0000><U+0000><U+0000><U+0000>@<U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><F0>"<U+0001><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000>@<U+0000>8
^
PR: 236192
Approved by: portmgr blanket
This plugin allows Bitlbee to communicate with Mastodon instances. Mastodon
is a free, open-source, decentralized microblogging network. Bitlbee is an
IRC server connecting to various other text messaging services. You run
Bitlbee and connect to it using an IRC client, then configure Bitlbee to
connect to other services, such as a Mastodon instance where you already
have an account. The benefit is that you can now use any IRC client you
want to connect to Mastodon.
WWW: https://alexschroeder.ch/software/Bitlbee_Mastodon
PR: 235731
Submitted by: tobias.rehbein@web.de
Reviewed by: mat
Approved by: mat (mentor)
Differential Revision: https://reviews.freebsd.org/D19205
- hexchat requires Python 3
- Specify PYTHON_VER in MESON_ARGS since each ports might be built with
different Python versions
PR: 235644
Submitted by: w.schwarzenfeld@utanet.at
Reported by: Philipp Engel <kidon@posteo.de>
Approved by: Piotr Kubaj <pkubaj@anongoth.pl> (maintainer)
2019-01-31 mail/dovecot-pigeonhole04: End of Life upstream, use mail/dovecot-pigeonhole instead
2019-01-31 multimedia/pyjama: Unmaintained upstream
2019-01-31 devel/py-omniorb-3: Uses legacy version of omniORB, consider using devel/py-omniorb
2019-01-31 mail/dovecot22: End of Life upstream, use mail/dovecot instead
2019-01-31 devel/hs-uuagc-bootstrap: No release since 2011
2019-01-31 sysutils/hs-angel: No releases since 2016
2019-01-31 devel/hs-uuagc: No release since 2015
2019-01-31 ports-mgmt/hs-porte: No updates since 2010
2019-02-01 net/pdb: Depends on expired net/py-pcs
2019-02-01 irc/iroffer: Abandoned upstream
2019-02-03 sysutils/fusefs-wdfs: Abandonware, functionally incomplete, has problems with caching
2018-12-19 net/py-pcs: Broken for more than 6 months
- Add NLS option
Since version v1.7.0, ZNC UI has translations for different languages.
- Switch to CMake
CMake build was added since version v1.7.0, and the ZNC UI translation
is built and installed just through CMake.
Autoconf will be removed from ZNC in the future and CMake will be the
only build option.
- Set PYTHON option as default
Now that znc-buildmod requires Python when CMake is used (as a runtime
dependency).
Changelog: https://wiki.znc.in/ChangeLog/1.7.2
Bitlbee plugin to allow connections to the discord chat service.
A more lightweight alternative to using bitlbee compiled with
libpurple support.
WWW: https://github.com/sm00th/bitlbee-discord
PR: 234007
Submitted by: Arthur Pirika <arfy32@gmail.com>
Reviewed by: koobs, ndowens@yahoo.com
a symbol matches multiple clauses the last one takes precedence. If the
catch-all is last it captures everything. In the case of Qt5 libraries
this caused all symbols to have a Qt_5 label while some should have
Qt_5_PRIVATE_API. This only affects lld because GNU ld always gives the
catch-all lowest priority.
Older versions of Qt5Webengine exported some memory allocation symbols from
the bundled Chromium. Version 5.9 stopped exporting these [1] but the
symbols were kept as weak wrappers for the standard allocation functions to
maintain binary compatibility. [2][3] The problem is that the call to the
standard function in these weak wrappers is only resolved to the standard
function if there's a call to this standard function in other parts of
Qt5Webengine, because only then is there a non-weak symbol that takes
precedence over the weak one. If there's no such non-weak symbol the call
in the weak wrapper resolves to the weak wrapper itself creating an infinite
call loop that overflows the stack and causes a crash. Some of the
allocation functions are variants of C++ new and delete and it probably
depends on the compiler whether these variants are used in other parts of
Qt5Webengine.
Remove the weak wrappers (make them Linux specific). This isn't binary
compatible but we are already breaking that with the changes to the symbol
versions.
[1] 5c2cbfccf9
[2] 2ed5054e3a
[3] 009f5ebb4b
Bump all ports that depend on Qt5.
PR: 234070
Exp-run by: antoine
Approved by: kde (adridg)
Previous 5.0.0 port was a beta; this is the first real KF5- and Qt5-
compatible release. The release notes say "too many changes to be listed",
since the previous stable was six years ago. Since 5.0.0-beta1, several
(unnamed) bugfixes.
While here, fix up USES=python. KVIrc is only compatible with Python 2.7.
MFH: 2019Q1
Ports that build out of source now simply can use "USES=cmake"
instead of "USES=cmake:outsource". Ports that fail to build
out of source now need to specify "USES=cmake:insource".
I tried to only set insource where explictely needed.
PR: 232038
Exp-run by: antoine
defined via Mk/bsd.default-versions.mk which has moved from GCC 7.4 t
GCC 8.2 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, as a double check, everything INDEX-11 showed depending on lang/gcc7.
PR: 231590