[kde-freebsd] [Bug 194762] [new port] devel/qtserialport
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194762 --- Comment #11 from fernando.apesteg...@gmail.com --- (In reply to Raphael Kubo da Costa from comment #10) > Landed, thank you very much. Terrific. Thanks! -- You are receiving this mail because: You are the assignee for the bug. ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
[kde-freebsd] [Bug 187463] www/webkit-qt4 uses base g++ as linker
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187463
Justin Hibbits changed:
What|Removed |Added
CC||jhibb...@freebsd.org
--- Comment #2 from Justin Hibbits ---
Adding 'LDFLAGS+= -B/usr/local/bin' (should probably be '${LOCALBASE}/bin', but
this hack worked) in the powerpc Makefile block fixes this, too.
--
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] [SVN Commit] area51
On Tue, 04 Nov 2014 09:39:57 +0100 Schaich Alonso wrote: > On Mon, 03 Nov 2014 09:54:18 + > Max Brazhnikov wrote: > > > On Wed, 16 Jul 2014 08:41:22 -0700 Alonso Schaich wrote: > > > SVN commit 10180 by aschai: > > > > > > Update telepathy to 0.8.0. > > > > > > Ports provided by T.C.Berner via Mailing List. I remove PORTREVISION as > > > this is > > > a version bump. > > > > > > Hi Alonso, > > > > What the status of these ports? are they ready for merging to the portstree? > > > > Max > > Hi > > While I don't use telepathy myself, I heard no complaints about those > ports and they've been in area51 for quite some time, so I guess they > are. ok, I'll assume they are not :) and will follow usual testing routine. ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] coreutils
On Wed, 05 Nov 2014 03:09:06 -0200 brunomaxi...@openmailbox.org wrote: > Hi folks, > > I notice coreutils is a dependency for kde, specifically kdepim. But I > tried to build kdepim removing the coreutils from Makefile and it builds > fine. Which are the needs to depend on coreutils? Could coreutils be > removed from KDE? > And what about gcc and bash? Are they necessary too? I have tried to > change my default shell to /bin/sh on Debian + KDE and KDE stopped to > log in, but here FreeBSD I use /bin/sh as default and KDE works > perfectly. So why bash dependency? KDE cannot work with native FreeBSD > components, besides FreeBSD has its own "coreutils" and shell? > > Thanks for answer. Hi, KDE doesnot depend on GCC. A component of it, namely kactivitymanagerd needs C++11 support to build a working binary (it could build but failed at runtime), and C++11 support was originally only availible with ports gcc or WITH_CLANG_IS_CC - however the later became the default in FreeBSD 10, so there's no direct GCC dependency any more. Packages used by KDE could be depending on it though. Bash is depended on by KDE components that install bash scripts, i.e. have bash as a runtime requirement. Coreutils was commented on by Tobias in his reply. Alonso pgp6qraum4jpE.pgp Description: PGP signature ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
[kde-freebsd] [SVN Commit] area51/CALLIGRA/editors/calligra
SVN commit 10461 by makc: editors/calligra: - add dependence on textproc/libodfgen and graphics/libetonyek - fix plist M +3 -1 Makefile M +34 -19pkg-plist ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
[kde-freebsd] [Bug 194566] [exp-run] Update Qt5 to 5.3.2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194566 Raphael Kubo da Costa changed: What|Removed |Added Status|In Discussion |Issue Resolved Resolution|--- |FIXED --- Comment #14 from Raphael Kubo da Costa --- Landed at long last! -- You are receiving this mail because: You are on the CC list for the bug. ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
[kde-freebsd] [Bug 194088] www/webkit-qt5 needs uninstall before build
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194088 Raphael Kubo da Costa changed: What|Removed |Added Status|Open|Issue Resolved Resolution|--- |FIXED --- Comment #4 from Raphael Kubo da Costa --- Fixed at last! Thanks for staying with us. -- You are receiving this mail because: You are the assignee for the bug. ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
[kde-freebsd] [Bug 194762] [new port] devel/qtserialport
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194762 Raphael Kubo da Costa changed: What|Removed |Added Status|Needs Triage|Issue Resolved Resolution|--- |FIXED --- Comment #10 from Raphael Kubo da Costa --- Landed, thank you very much. -- You are receiving this mail because: You are the assignee for the bug. ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
[kde-freebsd] [Bug 194088] www/webkit-qt5 needs uninstall before build
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194088
--- Comment #3 from commit-h...@freebsd.org ---
A commit references this bug:
Author: rakuco
Date: Wed Nov 5 09:39:30 UTC 2014
New revision: 372179
URL: https://svnweb.freebsd.org/changeset/ports/372179
Log:
Update Qt5 ports to 5.3.2.
Proudly presented by the KDE on FreeBSD team, with several guest stars.
This update took way longer than initially expected due to us previously
accumulating assumptions and changes to Qt's build system that finally bit
us back with the 5.3 release series, so we had to do a fair amount of
cleanup.
New ports:
- comms/qt5-serialport: Qt functions to access serial ports, originally
based on work by Fernando Apesteguia. [1]
- devel/qt5-qdoc: Qt documentation generator, the Qt5 equivalent of
devel/qt4-qdoc3. Originally worked on by Tobias Berner.
It had already been half-split from devel/qt5-buildtools,
we just needed to finish the work.
Dead ports:
- devel/qt5-qmldevtools: Merged into lang/qt5-qml.
Minor changes:
- devel/qt5: Add x11/qt5-x11extras and the new ports to the dependency list.
- graphics/qt5-imageformats: The port now supports the JPEG2000, WEBP,
Direct Draw Surface and ICNS formats.
- multimedia/qt5-multimedia: The ALSA and PULSEAUDIO options are now
mutually exclusive due to changes introduced in
Qt 5.3.0 (the ALSA code is now a proper plugin
that is only built if PulseAudio is not used).
- x11/qt5-x11extras: Add USE_LDCONFIG since the port installs a shared
library.
The big changes:
- bsd.qt.mk: Set QMAKESPEC instead of QMAKEPATH. [3]
QMAKEPATH does much more than we want now that we call qmake from the top
of ${WRKSRC}. qmake uses QMAKEPATH when evaluating the QMAKE_MKSPECS
property, which is in turn used by qt_config.pri to load the .pri files in
mkspecs/modules.
In practice, this means that if people have an older Qt installation those
files will be used and QT_CONFIG will have values such as "gui" even if
one is building a port like textproc/qt5-xml, which passes -no-gui to the
configure script. Consequently, unintended code paths may be enabled or
the configuration step can just fail if the .pro files expect values that
are not present in the system-wide, older .pri files.
We avoid all those problems if we use QMAKESPEC, as qmake does not take
its value into account when evaluating the QMAKE_MKSPECS property and will
only parse the files in the mkspec's directory (mkspecs/freebsd-clang, for
example, instead of all the files in mkspecs).
- Stop explicitly passing ${LOCALBASE} to the compiler. [3]
qmake's behavior has changed in Qt 5, and the paths set in QMAKE_INCDIR
and QMAKE_LIBDIR in the mkspecs are passed before any others, such as the
ones in the build directory themselves.
In practice, this means that we end up with linker calls like this:
c++ -o libfoo.so foo.o bar.o -L/usr/local/lib -L/wrkdir/build/lib
-lQt5Gui -lQt5Core
So if one already has Qt installed in the system, the older, already
present version of the libraries in /usr/local/lib will be used instead of
the newly-built ones in /wrkdir/build/lib.
QTBUG-40825 discusses this behavior upstream, but there has been no
agreement on a solution yet.
For now, the solution adopted is to make the compiler and the linker aware
of those paths but only try them last after all others, and this is
achieved by setting the CPATH and LIBRARY_PATH environment variables when
qmake is being used.
In addition to setting them in CONFIGURE_ENV and MAKE_ENV, we also need to
stop changing QMAKE_INCDIR and QMAKE_LIBDIR as well as filter those paths
from the pkg-config calls qtbase's configure script makes.
- Call qmake from the root of the ${WRKSRC}.
In Qt 5.3, Qt's build infrastructure has undergone some changes that make
our previous approach of calling qmake from the directories we want to
build stop working. Things would break even more in Qt 5.4, in which
qtbase's configure script does not accept the -process, -fully-process and
-dont-process arguments anymore (it always behaves as if -process had been
used).
Bite the bullet and start calling qmake from ${WRKSRC}. The largest part of
this change involves changing lines in Makefiles from
WRKSRC_SUBDIR=foo/bar
to
BUILD_WRKSRC=${WRKSRC}/foo/bar
INSTALL_WRKSRC=${WRKSRC}/foo/bar
as well as adding patches to .pro files to avoid entering other
subdirectories and removing post-configure targets that are not necessary
anymore.
Since qmake needs to be called from the top of ${WRKSRC} anyway, we can
also simpli
[kde-freebsd] [Bug 194566] [exp-run] Update Qt5 to 5.3.2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194566
--- Comment #13 from commit-h...@freebsd.org ---
A commit references this bug:
Author: rakuco
Date: Wed Nov 5 09:39:30 UTC 2014
New revision: 372179
URL: https://svnweb.freebsd.org/changeset/ports/372179
Log:
Update Qt5 ports to 5.3.2.
Proudly presented by the KDE on FreeBSD team, with several guest stars.
This update took way longer than initially expected due to us previously
accumulating assumptions and changes to Qt's build system that finally bit
us back with the 5.3 release series, so we had to do a fair amount of
cleanup.
New ports:
- comms/qt5-serialport: Qt functions to access serial ports, originally
based on work by Fernando Apesteguia. [1]
- devel/qt5-qdoc: Qt documentation generator, the Qt5 equivalent of
devel/qt4-qdoc3. Originally worked on by Tobias Berner.
It had already been half-split from devel/qt5-buildtools,
we just needed to finish the work.
Dead ports:
- devel/qt5-qmldevtools: Merged into lang/qt5-qml.
Minor changes:
- devel/qt5: Add x11/qt5-x11extras and the new ports to the dependency list.
- graphics/qt5-imageformats: The port now supports the JPEG2000, WEBP,
Direct Draw Surface and ICNS formats.
- multimedia/qt5-multimedia: The ALSA and PULSEAUDIO options are now
mutually exclusive due to changes introduced in
Qt 5.3.0 (the ALSA code is now a proper plugin
that is only built if PulseAudio is not used).
- x11/qt5-x11extras: Add USE_LDCONFIG since the port installs a shared
library.
The big changes:
- bsd.qt.mk: Set QMAKESPEC instead of QMAKEPATH. [3]
QMAKEPATH does much more than we want now that we call qmake from the top
of ${WRKSRC}. qmake uses QMAKEPATH when evaluating the QMAKE_MKSPECS
property, which is in turn used by qt_config.pri to load the .pri files in
mkspecs/modules.
In practice, this means that if people have an older Qt installation those
files will be used and QT_CONFIG will have values such as "gui" even if
one is building a port like textproc/qt5-xml, which passes -no-gui to the
configure script. Consequently, unintended code paths may be enabled or
the configuration step can just fail if the .pro files expect values that
are not present in the system-wide, older .pri files.
We avoid all those problems if we use QMAKESPEC, as qmake does not take
its value into account when evaluating the QMAKE_MKSPECS property and will
only parse the files in the mkspec's directory (mkspecs/freebsd-clang, for
example, instead of all the files in mkspecs).
- Stop explicitly passing ${LOCALBASE} to the compiler. [3]
qmake's behavior has changed in Qt 5, and the paths set in QMAKE_INCDIR
and QMAKE_LIBDIR in the mkspecs are passed before any others, such as the
ones in the build directory themselves.
In practice, this means that we end up with linker calls like this:
c++ -o libfoo.so foo.o bar.o -L/usr/local/lib -L/wrkdir/build/lib
-lQt5Gui -lQt5Core
So if one already has Qt installed in the system, the older, already
present version of the libraries in /usr/local/lib will be used instead of
the newly-built ones in /wrkdir/build/lib.
QTBUG-40825 discusses this behavior upstream, but there has been no
agreement on a solution yet.
For now, the solution adopted is to make the compiler and the linker aware
of those paths but only try them last after all others, and this is
achieved by setting the CPATH and LIBRARY_PATH environment variables when
qmake is being used.
In addition to setting them in CONFIGURE_ENV and MAKE_ENV, we also need to
stop changing QMAKE_INCDIR and QMAKE_LIBDIR as well as filter those paths
from the pkg-config calls qtbase's configure script makes.
- Call qmake from the root of the ${WRKSRC}.
In Qt 5.3, Qt's build infrastructure has undergone some changes that make
our previous approach of calling qmake from the directories we want to
build stop working. Things would break even more in Qt 5.4, in which
qtbase's configure script does not accept the -process, -fully-process and
-dont-process arguments anymore (it always behaves as if -process had been
used).
Bite the bullet and start calling qmake from ${WRKSRC}. The largest part of
this change involves changing lines in Makefiles from
WRKSRC_SUBDIR=foo/bar
to
BUILD_WRKSRC=${WRKSRC}/foo/bar
INSTALL_WRKSRC=${WRKSRC}/foo/bar
as well as adding patches to .pro files to avoid entering other
subdirectories and removing post-configure targets that are not necessary
anymore.
Since qmake needs to be called from the top of ${WRKSRC} anyway, we can
also simpl
[kde-freebsd] [Bug 194762] [new port] devel/qtserialport
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194762
--- Comment #9 from commit-h...@freebsd.org ---
A commit references this bug:
Author: rakuco
Date: Wed Nov 5 09:39:30 UTC 2014
New revision: 372179
URL: https://svnweb.freebsd.org/changeset/ports/372179
Log:
Update Qt5 ports to 5.3.2.
Proudly presented by the KDE on FreeBSD team, with several guest stars.
This update took way longer than initially expected due to us previously
accumulating assumptions and changes to Qt's build system that finally bit
us back with the 5.3 release series, so we had to do a fair amount of
cleanup.
New ports:
- comms/qt5-serialport: Qt functions to access serial ports, originally
based on work by Fernando Apesteguia. [1]
- devel/qt5-qdoc: Qt documentation generator, the Qt5 equivalent of
devel/qt4-qdoc3. Originally worked on by Tobias Berner.
It had already been half-split from devel/qt5-buildtools,
we just needed to finish the work.
Dead ports:
- devel/qt5-qmldevtools: Merged into lang/qt5-qml.
Minor changes:
- devel/qt5: Add x11/qt5-x11extras and the new ports to the dependency list.
- graphics/qt5-imageformats: The port now supports the JPEG2000, WEBP,
Direct Draw Surface and ICNS formats.
- multimedia/qt5-multimedia: The ALSA and PULSEAUDIO options are now
mutually exclusive due to changes introduced in
Qt 5.3.0 (the ALSA code is now a proper plugin
that is only built if PulseAudio is not used).
- x11/qt5-x11extras: Add USE_LDCONFIG since the port installs a shared
library.
The big changes:
- bsd.qt.mk: Set QMAKESPEC instead of QMAKEPATH. [3]
QMAKEPATH does much more than we want now that we call qmake from the top
of ${WRKSRC}. qmake uses QMAKEPATH when evaluating the QMAKE_MKSPECS
property, which is in turn used by qt_config.pri to load the .pri files in
mkspecs/modules.
In practice, this means that if people have an older Qt installation those
files will be used and QT_CONFIG will have values such as "gui" even if
one is building a port like textproc/qt5-xml, which passes -no-gui to the
configure script. Consequently, unintended code paths may be enabled or
the configuration step can just fail if the .pro files expect values that
are not present in the system-wide, older .pri files.
We avoid all those problems if we use QMAKESPEC, as qmake does not take
its value into account when evaluating the QMAKE_MKSPECS property and will
only parse the files in the mkspec's directory (mkspecs/freebsd-clang, for
example, instead of all the files in mkspecs).
- Stop explicitly passing ${LOCALBASE} to the compiler. [3]
qmake's behavior has changed in Qt 5, and the paths set in QMAKE_INCDIR
and QMAKE_LIBDIR in the mkspecs are passed before any others, such as the
ones in the build directory themselves.
In practice, this means that we end up with linker calls like this:
c++ -o libfoo.so foo.o bar.o -L/usr/local/lib -L/wrkdir/build/lib
-lQt5Gui -lQt5Core
So if one already has Qt installed in the system, the older, already
present version of the libraries in /usr/local/lib will be used instead of
the newly-built ones in /wrkdir/build/lib.
QTBUG-40825 discusses this behavior upstream, but there has been no
agreement on a solution yet.
For now, the solution adopted is to make the compiler and the linker aware
of those paths but only try them last after all others, and this is
achieved by setting the CPATH and LIBRARY_PATH environment variables when
qmake is being used.
In addition to setting them in CONFIGURE_ENV and MAKE_ENV, we also need to
stop changing QMAKE_INCDIR and QMAKE_LIBDIR as well as filter those paths
from the pkg-config calls qtbase's configure script makes.
- Call qmake from the root of the ${WRKSRC}.
In Qt 5.3, Qt's build infrastructure has undergone some changes that make
our previous approach of calling qmake from the directories we want to
build stop working. Things would break even more in Qt 5.4, in which
qtbase's configure script does not accept the -process, -fully-process and
-dont-process arguments anymore (it always behaves as if -process had been
used).
Bite the bullet and start calling qmake from ${WRKSRC}. The largest part of
this change involves changing lines in Makefiles from
WRKSRC_SUBDIR=foo/bar
to
BUILD_WRKSRC=${WRKSRC}/foo/bar
INSTALL_WRKSRC=${WRKSRC}/foo/bar
as well as adding patches to .pro files to avoid entering other
subdirectories and removing post-configure targets that are not necessary
anymore.
Since qmake needs to be called from the top of ${WRKSRC} anyway, we can
also simpli
