json-c website and download locations have changed, the project is now
hosted on Github.
Signed-off-by: Sagaert Johan <sagaert.johan@skynet.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
old SITE is now password-protected
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
old SITE is now password-protected
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
- old SITE is now password-protected
- add hash
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
If libatomic_ops was enabled, then the host-erlang dependency was lost.
Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Snappy doesn't configure without host pkg-config, causing this totally
unhelpful diagnostic from autoconf:
configure.ac:42: error: possibly undefined macro: AC_DEFINE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:44: error: possibly undefined macro: AC_MSG_FAILURE
So add host-pkgconf to the package's DEPENDENCIES list.
Signed-off-by: Steve James <ste@junkomatic.net>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To fix:
CVE-2013-7041 - use case sensitive comparison in pam_userdb
CVE-2014-2583 - potential path traversal issue in pam_timestamp
Also add hash file (computed, the hash files upstream cover up to 1.1.7)
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes:
CVE-2014-8142 - Use after free vulnerability in unserialize()
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes CVE-2014-1569 - The definite_length_decoder function in
lib/util/quickder.c in Mozilla Network Security Services (NSS) before
3.16.2.4 and 3.17.x before 3.17.3 does not ensure that the DER encoding
of an ASN.1 length is properly formed, which allows remote attackers to
conduct data-smuggling attacks by using a long byte sequence for an
encoding.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Use proper status messages, make spacing standard instead of a mix of
spacing/tabbing, drop boringly obvious comment from the header.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The CF_LIB_SONAME macro doesn't work when cross compiling so we need to
specify the lib name for libgpm explicitly. While at it make gpm support
explicit in the form of --without-gpm when it's not selected and adding
it to dependencies when it is. Fixes:
http://autobuild.buildroot.net/results/32a/32a5ba3905772a3f2f2ec9d1b290a109fe22d9f9/
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When running 'make printvars', the output stops at the time we dump the
Linux related variables, with:
linux/linux.mk:109: *** Recursive variable `LINUX_TARGET_NAME'
references itself (eventually). Stop.
And that's expected, since we have:
109 LINUX_TARGET_NAME = $(LINUX_IMAGE_NAME)
[...]
112 ifeq ($(LINUX_IMAGE_NAME),)
113 LINUX_IMAGE_NAME = $(LINUX_TARGET_NAME)
114 endif
Even though they are defined in a way that ensures they are in fact not
recursively defined (the if-block ensures that), 'printvars' does dump
all our variables by evaluating all of them, which in that specific case
implies they are recursively defined.
Fix that by explicitly setting LINUX_IMAGE_NAME in each if-block.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, ncurses creates symlinks from the non-'w' variants to the
equivalent 'w' variant, but forgets to do so for pkg-config files.
To be able to share the same list between the libraries and the
pkg-config files to symlink, just trim the 'lib' prefix of libraries in
the definition, and just add it back at the time we need it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Move the definition of libraries to install before it is actually used.
Also, in a coming changeset, it will also be used to know which
pkg-config files to symlink.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For a shared-only build, do not create the symlinks to the static
libraries, since they do not exist.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
No need to duplicate the host-pkgconf dependency on the Qt case, we
already depend on it in the general case.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In case the libgcrypt development files are present on the host system,
collectd's ./configure will mistakenly try to use them and will call the
host system's libgcrypt-config, thus leading it to use path to the host
system includes and libraries.
Fix that in two ways:
- explicitly disable libgcrypt support when libgcrypt is not enabled;
- pass the complete path to libgcrypt-config when libgcrypt is enabled.
However, collectd's configure.ac is utterly broken. The code in
configure.ac has special code to check for libgcrypt-config, and use
whatever is provided via --with-libgcrypt=/path/to/libgcrypt-config. But
that is promptly forgotten because they then call the AM_PATH_LIBGCRYPT
macro, that just does it all again from scratch, and does not use the
value previously found.
Instead, we set LIBGCRYPT_CONFIG in the environment and point it to our
own libgcrypt-config.
Should fix numerous build issues:
http://autobuild.buildroot.net/results/ad4/ad408aef5fb92fe9e031c7dbaf6999776b40ace4/http://autobuild.buildroot.net/results/967/96735bfa91bcf2e3dff89f69c0a12ed406e9efb9/
...
http://autobuild.buildroot.net/results/3bd/3bdd9bdffb1d55414787d38fc2656d7a3391a957/
...
(the first two are with the paranoid wrapper, the third one was before
the paranoid wrapper.)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@openwide.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
