note that ${SOURCEFORGE_MIRROR} in SRC_URI did not work
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
a patch better than mine was applied mainline
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
optional on distros supporting pulseaudio
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
xfce4-pulseaudio-plugin depends on gtk3 panel libs.
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Upgrade inetutils from 1.9.2 to 1.9.4.
* add homepage
* update inetutils/version.patch
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
Conflicts:
meta-networking/recipes-connectivity/inetutils/inetutils/telnetd-Fix-deadlock-on-cleanup.patch
*Modify SRC_URI.
*Modify chksum of file COPYING and LICENSE,since year changed,
and the LICENSE explanation for file base64.c, md5.c and types.h
was deleted.But the LICENSE has not been changed.
Signed-off-by: Li Xin <lixin.fnst@cn.fujitsu.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
When doing a multilib build, /usr/lib is still created but not collected
into FILES_${PN} by default, resulting in a QA error. Adding both
${libdir} and ${nonarch_libdir} catches all scenarios.
It also turns out that the previous do_install_append would throw an error
in a multilib build since systemd always installs to .../lib/... but
${libdir] would point at .../lib64/...
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
The 5 patches which are deleted have been in the v2.19
Signed-off-by: Jianchuan Wang <jianchuan.wang@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
after cmake is upgrade to 3.2.2, the /var/run dir is not created, so
not need to remove it.
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
After swig upgrade to 3.0.6, build the recipes which
depends on python-m2crypto will occur errors like this:
"SALT_LEN = m2.PKCS5_SALT_LEN
AttributeError: 'module' object has no attribute 'PKCS5_SALT_LEN'"
Reference
https://github.com/martinpaljak/M2Crypto/issues/60#issuecomment-75735489
Signed-off-by: Li Xin <lixin.fnst@cn.fujitsu.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
The 2.4 version is the only version available so makes no sense to set
it as lower preference.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
The patch has not been available in the 2.4 version form and thus the
recipe was unbuildable.
Fix by removing the patch file, which is unused, and the reference for
it from the recipe.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Update the checksum of COPYING,since the date in it has been changed,
but the LICENSE has not been changed.
Signed-off-by: Li Xin <lixin.fnst@cn.fujitsu.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* add several pkg configs and libsamplerate0 dependency to vlc.inc
* update patches 0003 and 0004
* add patch to use tremor's libvorbisidec rather than libvorbisdec
* add patch to fix luaL_checkint and luaL_optint (deprecated in lua 5.3)
Signed-off-by: Tim Orling <TicoTimo@gmail.com>
default to compile with libgphoto2, thus no change to old behaviour.
Signed-off-by: Max Krummenacher <max.oss.09@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
With the update of gphoto to a version with the 2.5 API gvfs do_compile
failes with:
gvfs-1.10.1/daemon/gvfsbackendgphoto2.c:1648:35: error: request for member 'name' in something not a structure or union
| DEBUG (" '%s' '%s' '%s'", info.name, info.path, info.library_filename);
and others.
This backports the upstream fix.
Signed-off-by: Max Krummenacher <max.oss.09@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* Convert from Module::Build to ExtUtils::MakeMaker
* Temporarily use github repository until upstream merges change
Signed-off-by: Tim Orling <TicoTimo@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* Convert from Module::Build to ExtUtils::MakeMaker
* Temporarily use github repository until change is merged upstream
Signed-off-by: Tim Orling <TicoTimo@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* Builds with ExtUtils::MakeMaker rather than Module::Build
* Author change
Signed-off-by: Tim Orling <TicoTimo@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
The bluetooth.service runs bluetoothd to manage bluetooth devices, if
present, in the system. By design, it should be running in either of
two cases:
1. A userspace utility (e.g. networkmanager) has made a dbus request
for bluetooth services provided by org.bluez. Even without this
patch, the bluetooth.service gets run via dbus activation under the
systmed aliased name 'dbus-org-bluez.service'. Perfect!
2. A bluetooth device is added to the system. When a bluetooth device
is added, udev triggers the special systemd target, bluetooth.target
intended to pull in any services needed for bluetooth linked under
bluetooth.target.wants.
Enable bluetooth.service so it gets linked under bluetooth.target.wants
and bluetoothd gets started when a user adds a bluetooth device to the
system.
To be clear, this isn't forcing bluetooth to be running all the time---
only when either of #1 or #2 are true.
Signed-off-by: Ash Charles <ashcharles@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
