Currently, wayland support is enabled when the wayland package is
enabled, not when the FreeRDP wayland client is enabled.
But the dependency on libxkbcomon is only enforced from Config.in
when the FreeRDP wayland client is enabled., but is added to build
dependencies when the wayland package is enabled.
As such, we can end up in a situation where the FreeRDP wayland
client is disabled, the wayland package is enabled, and the
libxkbcommon package is also disabled, which casues the build to
fail with:
Makefile:539: *** libxkbcommon is in the dependency chain of
freerdp that has added it to its _DEPENDENCIES variable without
selecting it or depending on it from Config.in. Stop.
Change the build dependency to actually be on the FreeRDP client
being enabled.
Fixes;
http://autobuild.buildroot.net/results/dc3e11f7076a8355f3d2f9cb49c6325dcf7084bd
Signed-off-by: Adam Duskett <Adamduskett@outlook.com>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, FreeRDP uses pkg-config to find whether wayland is available.
When it is, it gets the CFLAGS and LDFLAGS and so on from pkg-config,
which is OK.
But I also gets the path to the wayland scanner from pkg-config. And
this points to the target one, when we really need the host one.
So we force-feed the correct path as a configure option.
Furthermore, wayland support needs libxkbcommon, so add this missing
dependency as well.
Fixes:
http://autobuild.buildroot.org/results/bdfe233ade36a56d0f65ef3c3d1698fca548beed/
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
FreeRDP now has support for writing to the journal, so we must ensure
proper dependency and correct options.
Partially fixes:
http://autobuild.buildroot.org/results/81aa66ddd88919295ccb5f34b527b737627263a7/
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, we only depend on host-pkgconf for gstreamer-0.x
However, we also need it at least for gstreamer-1.x and waylabnd, too.
But since FreeRDP is a cmake package, host-pkgconf is always pulled in
as a dependency by the cmake-package infrastructure.
So, drop the gstreamer-conditional host-pkgconf dependency.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Samuel Martin <s.martin49@gmail.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Remove patches that has been merged/updated upstream
0001-fix-building-shared-libs.patch:
CmakeLists packages are rewritten.
0002-add-support-for-tz-package:
dd93fd2b3d
0003-add-missing-define.patch:
656b3be02d
0004-ffmpeg30.patch:
b7b66968f9
Also add sha256sum for license file.
Signed-off-by: Adam Duskett <Adamduskett@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Peter: use 'depends on' for wayland to match X11 client]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, the only client we can build is the X11 client.
FreeRDP now has support for building a wayland client.
However, that means we need to rethink the way we build FreeRDP, because
of some "inconsistencies" in its build system. This is because FreeRDP's
buildsystem does not have orthogonal options; some of the options can be
used for different components.
For example, the set of X11 libraries needed to build the server is a
superset of the X11 libraries needed to build the X11 client. So,
whenever the server is enabled, it means the X11 libraries required to
build the X11 client are available.
Now, if the user also wants to build the waland client (but not the X11
client), there is no way to tell FreeRDP not to build the X11 client,
because there is a single option, WITH_CLIENT, to drive whether any of
the clients is built. The decision is made on the availability of the
required libraries. And since the server is enabled, the X11 libs
required to build the X11 client are available. So, we end up with the
X11 client, even though it is not wanted.
And conversely with wayland...
So, we redesign the way we build FreeRDP. WE do not care what is
actually built; we just build whatever is buildable with the current
set of enabled libraries. But at install time (both in staging/ and
target/) we remove whatever the user does not want.
We also take the opportunity to rename the X11 client option, so it is
coherent with the soon-to-be-introduced wayland client.
Note: since FreeRDP has gained new dependencies, we can not just
introduce the legacy option as-is, otherwise we run the risk that it
selects the new option even though the new FreeRDP dependencies are not
enabled, spitting out the infamous 'unmet direct dependencies" kconfig
error.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Previously, we expected the user to select gstreamer-0.x on his own,
to enable gstreamer support in FreeRDP. This could have been a bit
confusing to the user, as he may have enabled gst-1.x but FreeRDP did
only support gst-0.x.
Also, gstreamer support needs xlib-libxrandr, which was missing in
FreeRDP's dependencies, so it was never enabled (AFAICS).
(Re-)introduce support for gstreamer-0.x and gstreamer-1.x, since both
are supported.
We're doing it in a choice, and select whichever version the user chooses,
rather than automatically detect it as previosuly done. We can select the
gstreamer packages, as their dependencies are anyway already covered by the
ones of FreeRDP.
This also now requires xlib-libxrandr, so hide the choice if X.org is
not enabled, still offer the option of not using gstreamer if it is.
[Peter: Hide option if gstreamer{,1} aren't enabled,
Default to gstreamer{,1} support enabled
GStreamer 0.10 support needs host-pkgconf and libxml2]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, we're packaging FreeRDP from the stable-1.1 branch, which has
not evolved since march 2015 and hasn't seen any release (not even a
tag) since July 2013. It is by all purpose and means, dead.
Other packages that may use FreeRDP (like weston) are now migrating to,
or have already migrated to using the API from master, which has changed
a bit from what was available on the stable-1.1 branch. So, those
packages now FTBFS.
However, FreeRDP still has not done a release from their master branch;
the last tag dates back to September 2014 and there are 1850+ changes on
top of that tag.
So, switch to using the currently-latest commit from master.
This version can also use gstreamer-1.x (in addition to gst-0.x), which
needs quite some rework on how we handle the dependency on gstreamer.
Drop gstreamer support entirely, support for gst-0.x and gst-1.x will be
re-added in a followup patch.
Similarly, a wayland client can now be built, support for which will
be added in a subsequent path; it is currently forcibly disabled.
The way the libraries are built has changed: the previous single library
has been split in multiple libraries, each implementing parts of the RDP
protocol.
Slight rewording of the prompts:
- drop the 'install' for client and server.
- drop 'freerdp' from the client and server comment
The location of the server keys has changed, so copy them from the new
location.
Finally, drop patches 1 and 3, applied upstrem; rename remaining
patches.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Little bump to get small bug fixes.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, the keys are only installed if the server is enabled.
However, other packages (e.g. weston) may implement an RDP server,
using the FreeRDP library.
So, we must always install the key and certificate.
Install them world-readable so non-root users may start an RDP server
without requiring to generate their own keys.
Add a comment in the help text about key and certificate management.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This is mandatory for an RDP server to have a key and a certificate,
otherwise clients will refuse to connect to that server.
We install the key and certificate bundled in FreeRDP. The user can
install its own set using a post-build script if needed.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Samuel Martin <s.martin49@gmail.com>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
freerdp installs a library that other packages may use, so
we must also install it to staging.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Building the client or the server requires an X.Org stack.
Since freerdp can also be used for weston (wayland-based, hence no X.Org
stack), we may want to disable the client and server.
Conversely, even with an X.Org stack, we may want to enable either or
none if we're just interested in the library.
Add two options, one to enable the server, the other the client; the
client option defaults to 'Y' so that a previous .config can be re-used
as-is, and exhibit the same behaviour as before; the server option
defaults to 'N' as we were not ever building the server so far.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Samuel Martin <s.martin49@gmail.com>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Move the arch-spcific block up, so it does not interfere with followup
patches (mostly to ease review).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It is possible to build the libfreerdp standalone, without X.Org.
Having a libfreerdp will be usefull for the weston RDP compositor.
So, only select the strictly required X.Org library if X.Org is enabled,
and only build with Xcursor if it is enabled. Drop dependency on other
X.Org libraries, as they are not strictly required (or get pulled as
dependencies of the mandatory libXext).
Re-order the menuconfig, as freerdp is no longer an X-only application.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
FreeRDP still uses old-style variables (about linking interfaces), and
that causes a warning, which explicitly states it is targeted at
developers:
Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
interface. Run "cmake --help-policy CMP0022" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.
Target "freerdp-client" has an INTERFACE_LINK_LIBRARIES property which
differs from its LINK_INTERFACE_LIBRARIES properties.
INTERFACE_LINK_LIBRARIES:
[elided list of stuff]
LINK_INTERFACE_LIBRARIES:
This warning is for project developers. Use -Wno-dev to suppress it.
So, just get rid of it as instructed in that warning message itself.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Avoid a warning at configure time when gstreamer is missing.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since we bumped to CMake-3.1, the build of FreeRDP is broken:
CMake Error at channels/client/CMakeLists.txt:33 (list):
list sub-command REMOVE_DUPLICATES requires list to be present.
This has been fixed upstream, so just bump the version to get that fix.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In the line of commit 530693787b ("package/freerdp: do not use Neon
extensions when not available") done by Yann E. Morin, freerdp also
passes an explicit -mfloat-abi= flag, and defaults to softfp. This
obviously breaks badly when building an EABIhf system.
This commit therefore fixes freerdp.mk to pass the appropriate
ARM_FP_ABI value to freerdp's build system.
Fixes:
http://autobuild.buildroot.org/results/6ca/6ca9de1a11c675533baa68f7a6bf7b6af7cb4345/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Do not let FreeRDP decide whether it can use SE2 opcodes, it may well
fail to do so, because the heuristic is not working for
cross-compilation.
Also, we do have a Kconfig option stating whether we have SSE2 or not,
so reuse that.
Similar to the recent ARM+Neon fix.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
FreeRDP mis-detects the CPU, and may enable Neon extensions when it
should not. Not all ARM processors have Neon extensions.
Heck, what's more, none non-ARM processor has Neon extensions!
The regexp to detect the CPU is borked: 'arm*' will also match 'arc'
as well as 'arm'.
Do not let FreeRDP try to decide if it can use Neon extensions, we have
a Kconfig option for that, that we can use to force FreeRDP to use it or
not.
Should fix:
http://autobuild.buildroot.org/results/d4a/d4a61e686cf11d993d02ece0c4e2835a926603c2/http://autobuild.buildroot.org/results/234/2349d40ef8d658ab1cd7332eb1b42a75afcd423f/
...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Building the manpages requires xsltproc, which might not be available.
Also, who needs the manpages on the target anyway? ;-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To be consistent with the recent change of FOO_MAKE_OPT into FOO_MAKE_OPTS,
make the same change for FOO_CONF_OPT.
Sed command used:
find * -type f | xargs sed -i 's#_CONF_OPT\>#&S#g'
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
There has been no new release recently, and the 1.0 branch is out-dated.
The 1.1 branch has not been release-tagged since the last beta tag,
but it still continues to receive bug fixes, and is relatively stable.
The next major release should be 1.2.0, but it is still in beta, looks
like it is focused on Android, and was only recently tagged.
So, we use the latest cset from the 1.1 branch until there is a new
release (either 1.2.0 or 1.1.0), at which point we can revisit which
version we'll use.
Drop our patch, since the problem has been fixed upstream (with a more
complete solution.)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Apache licenses are referred to in a variety of ways; standardise these,
choosing a form which does not contain whitespace.
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
