Update the CONFLICTS definitions of ports in the following categories:
- accessibility
- archivers
- audio
- benchmarks
- biology
- cad
- chinese
- comms
- converters
An attempt has been made to use generic conflicts patterns that do not
have to be updated whenever a new version of a conflicting port is
added to the ports system.
There is a misunderstanding that the port being built/installed has to
be omitted from the conflicts pattern. This is not true - the port
being built is implicitly non-conflicting due to logic in bsd.port.mk.
Approved by: portmgr (implicit)
There have been lots of missing CONFLICTS_INSTALL entries, either
because conflicting ports were added without updating existing ports,
due to name changes of generated packages, due to mis-understanding
the format and semantics of the conflicts entries, or just due to
typoes in package names.
This patch is the result of a comparison of all files contained in
the official packages with each other. This comparison was based on
packages built with default options and may therefore have missed
further conflicts with optionally installed files.
Where possible, version numbers in conflicts entries have been
generalized, some times taking advantage of the fact that a port
cannot conflict with itself (due to logic in bsd.port.mk that
supresses the pattern match result in that case).
A few ports that set the conflicts variables depending on complex
conditions (e.g. port options), have been left unmodified, despite
probably containing outdated package names.
These changes should only affect the installation of locally built
ports, not the package building with poudriere. They should give an
early indication of the install conflict in cases where currently
the pkg command aborts an installation when it detects that an
existing file would be overwritten,
Approved by: portmgr (implicit)
While here, make sure gtk-update-icon-cache is only on run dependency
where added as a dependency
Enforce gtk3 to depend on gtk-update-icon-cache (previously it was
inheriting the dependency)
The Fcitx5 IME framework is the future version of the legacy Fcitx IME framework.
Main parts of Fcitx5:
- x11/xcb-imdkit
- textproc/fcitx5
Application supports libraries of Fcitx5:
- textproc/fcitx5-qt
- textproc/fcitx5-gtk
GUI configuration tool of Fcitx5:
- textproc/fcitx5-configtool
IME addons for Fcitx5:
- chinese/fcitx5-rime
- japanese/fcitx5-anthy
textproc/fcitx5 and chinese/fcitx cannot be installed at the same time right now, due to development environment and runtime conflicts users could possibly run into.
Submitted by: Ka Ho Ng <khng300@gmail.com>
Approved by: lwhsu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27667
as defined in Mk/bsd.default-versions.mk which has moved from GCC 8.3
to GCC 9.1 under most circumstances now after revision 507371.
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, everything INDEX-11 shows with a dependency on lang/gcc9 now.
PR: 238330
Options helpers are ineffective when set after bsd.port.options.mk.
DOCS_EXTRA_PATCHES_OFF is not needed. A build without DOCS is
already working via %%PORTDOCS%% in the plist even without
files/nodocs-doc_CMakeLists.txt (which also no longer applies).
Reported by: tobik (in D19553)
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
While here, chase some KDE4 ports and functionality, these are scheduled for
removal on 2018-12-31. Change the default option/flavor to QT5 where applicable
or use alternative toolkits like GTK.
Submitted by: tcberner
Reviewed by: adridg, jhale, rene, tcberner
Approved by: portmgr (implicit, flavor hook)
Differential Revision: https://reviews.freebsd.org/D17741
From now on, ports that depend on Qt4 will have to set
USES= qt:4
USE_QT= foo bar
ports depending on Qt5 will use
USES= qt:5
USE_QT= foo bar
PR: 229225
Exp-run by: antoine
Reviewed by: mat
Approved by: portmgr (antoine)
Differential Revision: →https://reviews.freebsd.org/D15540
Using ninja instead of make (1) can lead to significant speed ups while building.
Therefore switch from having the ninja generator opt-in to having it opt-out.
Previously cmake-ports that wanted to use ninja could set
CMAKE_NINJA=yes
now, ports that do not work with ninja can set
cmake:<existing args>,noninja
Note, that needing this should be an exception and most often points to a broken
cmake of the port.
The ports using cmake were modified
* removed USES=gmake, if ninja is used
* removed MAKE_ARGS, if ninja is used
* added the cmake-argument noninja if necessary
PR: 219629
PR: 213331
Exp-run by: antoine
Reviewed by: rakuco
Differential Revision: https://reviews.freebsd.org/D10748
KDE Frameworks is a collection of libraries and software frameworks by KDE
that serve as technological foundation for KDE Plasma 5 and KDE Applications
distributed under the GNU Lesser General Public License (LGPL) [1].
The work is based on what we have in the KDE testing repo [2].
This is the next big step in updating the KDE Desktop and its Applications
to anything less dusty.
With this change, `USES=kde:5` is now a valid option. Ports that need to depend
on KDE Framework can now set:
USES=kde:5
USE_KDE=<framework1> <framework2> ... <frameworkX>
For example: www/qupzilla-qt5 can depend on sysutils/kf5-kwallet via:
KWALLET_USE= KDE=wallet
I would like to thank Raphael and Adriaan for reviewing the ports in the testing
repo :)
[1] https://en.wikipedia.org/wiki/KDE_Frameworks
[2] http://src.mouf.net/area51/log/branches/plasma5
Reviewed by: rakuco, mat, groot_kde.org
Approved by: rakuco (maintainer)
Differential Revision: https://reviews.freebsd.org/D8329
- Clean up the Makefile.
- Follow some upstream recommendations (--with-data-packaging=archive,
--disable-renaming, -DICU_NO_USER_DATA_OVERRIDE).
- Patch makefiles to install static libraries with INSTALL_DATA so they
aren't stripped.
- Patch config/mh-bsd-gcc to sync with config/mh-linux-gcc.
- Fix endianness detection in ICU. The code wanted to use BYTE_ORDER
defined in machine/endian.h, but this isn't visible because ICU is
compiled with _XOPEN_SOURCE. Patch the code to use _BYTE_ORDER instead.
- Compile ICU with C++11 compiler to enable move constructors.
- Patch ICU to fix a problem with atomics in the case of a C++11 compiler
without C++11 header <atomic> (like Clang on FreeBSD 9).
- Bump all ports that depend on it due to library version change.
- Add USES=compiler:c++0x to some ports that pick up -std=c++0x from ICU
pkgconfig files.
- Add USES=compiler:c++11-lib to graphics/libcdr01 because it also needs
a C++11 runtime library now. Add this to all ports that depend on it
so their executables load the right libstdc++.so on FreeBSD 9.
PR: 205120
Exp-run by: antoine
Approved by: portmgr (antoine)
already had USES=pathfix, although it did nothing. For those ports, I
either removed it as they were handling the pkgconfig files differently
or I removed patches and substitutions that accomplished the same thing
as pathfix.
Differential Revision: https://reviews.freebsd.org/D850
Reviewed by: antoine, bapt, tijl
Approved by: portmgr (bapt)
The way we deal with iconv in base and ports across different FreeBSD
releases is complicated: 9.x does not have iconv.h in base, 10.1 has it with
a different prototype for iconv(3) and later versions have the right
iconv(3) prototype. And, in some cases (USES=iconv:{translit,wchar_t}), we
must always use the libiconv port.
This is why there are so many checks in Uses/iconv.mk: we need to know the
situation we currently have in order to decide whether to pull iconv from
converters/libiconv, whether to just use its header (and pull the library
from base) or whether to use everything from base.
r384038 adjusted several CMake-based ports, but did so in a way that was not
very scalable and required a few intrusive patches to some ports. Most ports
that have both USES=cmake and USES=iconv use variations of FindIconv.cmake
that behave similarly. This change passes the header and library values we
really want to use to CMake using the most common variable names, bypassing
the calls to find_path() and find_library() that would sometimes end up
finding the wrong file. The few ports that use different variable names have
had their Makefiles adjusted (we manually pass the values we want via
CMAKE_ARGS).
Other changes:
- chinese/fcitx: Explicitly set LIBICONV_LIBC_HAS_ICONV_OPEN=OFF as we
always want the version from ports because of USES=iconv:wchar_t.
- editors/calligra: Explicitly use iconv:translit because Kexi needs it.
- irc/weechat and irc/weechat-devel: The FindIconv.cmake patches could not
be entirely removed because the check_library_exists() calls are wrong.
Sent upstream: https://github.com/weechat/weechat/pull/513
- textproc/ctpp2: Use iconv:translit when the TRANSLITERATE option is used.
PORTREVISION has been bumped in editors/calligra and textproc/ctpp2 because
their dependency list has changed in 10.2 and later as the ports version is
always used now.
PR: 202798
Reviewed by: antoine, tijl
Approved by: portmgr (antoine)
For example (${OSVERSION} >= 900000 && ${OSVERSION} < 900021) is always true,
as is (${OSVERSION} > 900002 || ${OSVERSION} < 900000 && ${OSVERSION} > 800107).
Regarding patches, when an EXTRA_PATCHES is no longer needed, I remove it, when
it is always needed, I renamed it, in one case, I merged two patches.
Differential Revision: https://reviews.freebsd.org/D2209
- New port: chinese/brise Rime schema repository
- Update chinese/fcitx to 4.2.8.5.
- Update chinese/fcitx-chewing to 0.2.2.
- Update chinese/fcitx-cloudpinyin to 0.3.4.
- Update chinese/fcitx-configtool to 0.4.8.
- Update chinese/fcitx-libpinyin to 0.3.1.
- Update chinese/fcitx-rime to 0.3.1.
- Update chinese/fcitx-sunpinyin to 0.4.1.
- Update chinese/fcitx-table-extra to 0.3.7.
- Add LICENSE and update website (mainly move off Google Code)
for various ports.
- Update chinese/libpinyin to 1.1.0.
- Update chinese/librime to 1.1.
- Update chinese/opencc to 0.4.3.
- Update japanese/fcitx-anthy to 0.2.1.
- New port: japanese/fcitx-skk SKK support for Fcitx
- Update korean/fcitx-hangul to 0.3.0.
- Update textproc/fcitx-m17n to 0.2.3.
PR: ports/198743
Submitted by: maintainer, hiroto.kagotani@gmail.com, delphij
Where possible, correct a few instances where PORTDOCS was being used
to flag stuff in EXAMPLESDIR. For some ports, mostly those owned by
ruby@, PORTDOCS is applied to pretty much everything whether it's
documentation or example.
a zeising, kwm production, with help from dumbbell, bdrewery:
NEW XORG ON FREEBSD 9-STABLE AND 10-STABLE
This update switches over to use the new xorg stack by default on FreeBSD 9
and 10 stable, on osversions where vt(9) is available.
It is still possible to use the old stack by specifying WITHOUT_NEW_XORG in
/etc/make.conf .
FreeBSD 8-STABLE and released versions of FreeBSD still use
the old version.
A package repository with binary packages for new xorg will
be available soon.
This patch also contains updates of libxcb and related ports, pixman, as well
as some drivers and utilities.
Bump portrevisions for xf86-* ports, as well as virtualbox-ose-additions due
to xserver version change.
Apart from these updates, the way shared libraries are handled has been
changed for all xorg ports, as well as libxml2 and freetype, which means
ltverhack is gone and as a consequence shared libraries have been bumped.
The plan is that this change will make library bumps less likely in the
future.
All affected ports have had their portrevisions bumped as a consequence of
this.
Fix some issues where WITH_NEW_XORG weren't detected properly on CURRENT.
Update instructions, hardware support, and more notes can be found on
https://wiki.freebsd.org/Graphics
Thanks to: all testers, bdrewery and the FreeBSD x11@ team
exp-run by: bdrewery [1]
PR: ports/187602 [1]
Approved by: portmgr (bdrewery), core (jhb)
immodules.cache. gtk-query-immodules-2.0 has a new option,
--update-cache that does what we want too.
Use this new option.
While here, add stage support to non slave ports
Reviewed by: kwm (immodules part)
