The last upstream release supporting KDE4 was 10 months ago,
https://www.kde.org/announcements/announce-applications-17.08.3.php ,
and the kde@ team for FreeBSD has supported modern KDE (i.e. KDE
Frameworks, Plasma 5 and KDE Applications) for 4 months. Give a 4
month deprecation period to allow users to switch over.
Also deprecated: multimedia/kmplayer-kde4 (permission from jhale@)
Not deprecated, need to contact maintainers:
misc/krecipes-kde4
net-im/kmess-kde4
net/smb4k-kde4
textproc/uim-kde4
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
This is done for
* consistency,
* and to simplify the import of the newer KDE Plasma5 desktop and KDE applications
Bumps the dependencies.
Reviewed by: adridg
Differential Revision: https://reviews.freebsd.org/D12979
graphics/gphoto2: Update to 2.5.15
graphics/py-gphoto2: Update to 1.8.2
Also bump PORTREVISION of ports depending on these.
PR: 224611
Submitted by: bsam (graphics/libgphoto2)
Usage:
USES=eigen:<version>[,<type>]
version: 2 or 3 (required)
type: build (default), run
For example:
USES=eigen:2,build,run
will add a BUILD- and RUN_DEPENDS on math/eigen2, and
USES=eigen:3
will add a BUILD_DEPENDS on math/eigen3.
* Convert the existing ports to use it
- biology/iqtree: remove run time dependency (seemed not to be needed)
- graphics/movit: remove run time dependency (seemed not to be needed)
- science/avogadro: add run time dependeny (installed cmake file requires it to be present)
Reviewed by: rakuco, mat
Differential Revision: https://reviews.freebsd.org/D13702
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
The kipi-plugin-* ports are all built from the same tarball, which is also used
to build kipi-plugins-kde4 as well.
Upstream does not expect this to happen, and refers to libkipiplugins.so as the
"kipiplugins" target in CMake. Since we build everything separately, each
plugin's build system code does not know this target, which results in
-lkipiplugins (without -L/path/to) being passed to the linker instead of
/path/to/libkipiplugins.so.
Fix it by looking for libkipiplugins.so via CMake and using that result in each
port.
kipi-plugin-ipodexport needs an additional but similar fix, in that it should
look for libgpod using CMake instead of using pkg-config's results directly, as
the latter do not contain full paths.
Reviewed by: tcberner
Make sure libqlr-1.so's full path is passed to the linker, as -L${LOCALBASE} is
no longer being passed implicitly.
Submitted by: tcberner (area51 r12732)
Plasma5 ports
At the moment KDE ports use bsd.kde4.mk to handle their dependencies. When
working on the ports for KDE Frameworks and Plasma5 it seemed to be more
reasonable to create a new kde.mk instead of adding an bsd.kde5.mk.
The kde.mk in this review is a stripped down version of the one we are using in
the KDE Test repositories plasma5 branch [1] to only contain the parts relevant
to the current KDE4 ports in the portstree [2].
Changes to the KDE Ports needed by this:
Replace USE_KDE4 by USE_KDE [3]
Add USES=kde:4 [4]
[1] http://src.mouf.net/area51/view/branches/plasma5/KDE/Mk/Uses/kde.mk
[2] The version in the plasma5 branch also handles frameworks/plasma5 and
handles MASTER_SITES via a KDE_DIST variable similar to bsd.qt.mk for Qt
Ports -- I chose to leave this out for now, as the diff is already large
enough.
[3] I chose USE_KDE instead of USE_KDE4, USE_KDE5, USE_KDEX as the version we
want is already specified as argument to kde:<arg>
[4] For KDE Frameworks and Plasma5 ports this would be kde:5
PR: 210667
Approved by: portmgr, mat (mentor), rakuco (mentor)
Reviewed by: mat, rakuco
Differential Revision: https://reviews.freebsd.org/D6961
This patch replaces a bunch of ${CURDIR}/../../ by ${CURDIR:H:H};
the latter is considered proper contemporary usage by kde@ . The
patch is independent of other KDE4 infrastructure changes.
PR: 209303
Submitted by: Adriaan de Groot <groot@kde.org>, rakuco, T.C.Berner <tcberner@gmail.com> (kde)
longer. This is a no-op because KDE4_PREFIX is equal to LOCALBASE
Fix up properties for misc/kde4-l10n/files/bsd.l10n.mk to make svn happy.
PR: 209014 (partial)
Submitted by: myself
Approved by: portmgr (bapt)
Differential Revision: https://reviews.freebsd.org/D6542
This is a huge leap, as we are moving from 4.2.0 (released in August 2014) to
4.14.0 (released in October 2015). Version 4.14.0 is the last KDE4-based
release, and 5.0.0 will be based on KDE Frameworks 5.
Noteworthy port changes:
- Most patches in graphics/digikam-kde4 are no longer necessary.
- graphics/kipi-plugin-googledrive and graphics/kipi-plugin-picasaweb have
been merged into graphics/kipi-plugin-googleservices following what
upstream did to those plugins.
- astro/libkgeomap and graphics/libkface are no longer included in the
DigiKam tarball and are now completely independent ports whose tarballs
are released as part of KDE Applications.
- net/libmediawiki is neither included in the DigiKam tarball nor released
as a separate tarball, so we had to resort to fetching it from an older
DigiKam release which contains it.
- graphics/digikam-kde4 now has a runtime dependency on x11/kde4-runtime.
See bug 203222 for details.
A lot of people have contributed to this update over the years in our
experimental area51 repository. Tobias Berner (our usual suspect), Adriaan
de Groot, makc@, alonso@ and jhale@ at the very least.
PR: 203222
PR: 204623
Submitted by: Tobias Berner <tcberner@gmail.com>,
Adriaan de Groot <groot@kde.org>,
alonso,
jhale,
makc,
rakuco
This fixes digikam-kde4's build on 9.3 after the graphics/lensfun update in
r411373.
lensfun.h includes C++ code (class and template declarations) inside an
extern "C" block that causes base GCC to fail:
/usr/local/include/lensfun/lensfun.h:2506: error: template with C linkage
/usr/local/include/lensfun/lensfun.h:2508: error: template with C linkage
Take the dports patch to fix compilation with Lensfun 0.3.2
(14 DEC 2015, 0f159981176faa6da701f112bfe557b79804d468)
Digikam broke when lensfun was updated on 18 March 2016.
Approved by: just-fix-it
digiKam 4.2.0 which is currently in ports is quite old, and was moved along
with all releases older than 4.10.0 to another location in download.kde.org.
This should fix `make fetch' for graphics/digikam* and graphics/kipi-plugin*.
code incompatible with earlier versions; particularly, removal of CCI (the
Color Contribution Index of the lens, as defined by ISO 6728-83) [1] and
FOV1 ("field-of-view") [2] distortion model.
Four ports had to be patched to build against new lensfun (all fall under
`graphics' category): digikam-kde4, gimp-lensfun-plugin, hugin, rawstudio.
PR: 196182
Submitted by: Matthieu Volat (heavily modified)
Exp-run by: antoine
[1] https://sourceforge.net/p/lensfun/code/ci/f0c293
[2] https://sourceforge.net/p/lensfun/code/ci/048eb3
- New ports for exporting images to Dropbox and Google Drive:
graphics/kipi-plugin-dropbox
graphics/kipi-plugin-googledrive
Excerpt from area51 commit logs:
------------------------------------------------------------------------
r10303 | jhale | 2014-09-19 04:04:57 +0000 (Fri, 19 Sep 2014) | 13 lines
- Update digikam and friends to 4.2.0
- Drop "Enable" from Digikam options descriptions
- For kipi-plugins, only extract what we need to reduce extraction time
and file I/O
------------------------------------------------------------------------
r10183 | makc | 2014-07-18 22:07:34 +0000 (Fri, 18 Jul 2014) | 21 lines
Update DigiKam and Kipi plugins to 4.1.0. This incomplete update is based
on the patch submitted by Oleg Sidorkin <osidorkin@gmail.com> via
kde-freebsd mailing list.
astro/libkgeomap:
- Don't build demo application and thus remove dependence on libkexiv2
- Add build dependency on boost headers
graphics/kipi-plugin-gpssync
- Add build dependency on boost headers
GCC 4.2 in FreeBSD 8.X/9.X base is now too old to compile OpenEXR, so
GCC-based systems will upgrade to the default ports compiler (GCC 4.7
currently.)
Add two patches to OpenEXR to permit building it in a live system with
the older OpenEXR version installed. Bug report filed to upstream Github
at https://github.com/openexr/openexr/issues/130
Couple OpenEXR more tightly to ilmbase and require its exact .so
version.
Add UPDATING note, and bump PORTREVISION of all dependent ports.
Proto-STAGE hugin-devel, and mark it IGNORE because hugin is newer.
Approved by: portmgr (implicit for bumping PORTREVISION on unstaged ports)
Just setting USES=tar:bzip2 is not enough, as ports such as
graphics/kipi-plugin-facebook would still report an invalid distfile if
NO_BUILD was passed.
We now unconditionally set DISTNAME, DISTINFO_FILE and LICENSE besides USES.
Setting USES=bzip2 inside the NO_BUILD block caused problems for FreeBSD's
distfile fetcher, which apparently set that flag and was getting an invalid
distfile to fetch from the KDE mirrors.
The rest of the NO_BUILD block needs more attention, but I'll let makc@ and
jhale@ handle that since it's not my area.
