Google Code is a closing forge, libnfc has already made the move to
Github.
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Autogenerated from rename-patch.py (http://patchwork.ozlabs.org/patch/403345)
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.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>
Since the trailing slash is stripped from $($(PKG)_SITE) by pkg-generic.mk:
$(call DOWNLOAD,$($(PKG)_SITE:/=)/$($(PKG)_SOURCE))
so it is redundant.
This patch removes it from $(PKG)_SITE variable for BR consistency.
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In the Config.in file of package foo, it often happens that there are other
symbols besides BR2_PACKAGE_FOO. Typically, these symbols only make sense
when foo itself is enabled. There are two ways to express this: with
depends on BR2_PACKAGE_FOO
in each extra symbol, or with
if BR2_PACKAGE_FOO
...
endif
around the entire set of extra symbols.
The if/endif approach avoids the repetition of 'depends on' statements on
multiple symbols, so this is clearly preferred. But even when there is only
one extra symbol, if/endif is a more logical choice:
- it is future-proof for when extra symbols are added
- it allows to have just one strategy instead of two (less confusion)
This patch modifies the Config.in files accordingly.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
There is no benefit in using the shortened git revision hash. On the
contrary: the shorter the hash, the higher the risk of having collisions
with another commit.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch lines up the comments in Config.in files that clarify which
toolchain options the package depends on.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Note that libnfc has also switched from Subversion to Git.
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
libusb needs thread support, and so do other packages that depend on it.
[thomas.petazzoni@free-electrons.com: adds threads dependency to
libnfc-llp, which selects libnfc.]
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The libnfc package is currently at version 1.5.1 in Buildroot. This patch
bumps the version to a recent svn revision, for the following reasons.
* Version 1.5.1 is marked as "unstable" on the libnfc download site.
* The nfc-tools project at
http://code.google.com/p/nfc-tools/
includes a library that extends libnfc with LLCP functionality.
Unfortunately, to build this requires a libnfc version no lower than 1.6.
The version 1.6.0-rc1 Release Candidate does not build; svn commits to fix
the build problems have not yet been back-ported into a Release Candidate.
* The libfreefare package is currently at version 0.3.2 in Buildroot. To bump
this to the most recent version (0.3.4) also requires a libnfc version no
lower than 1.6.
I suggest that this patch be regarded as a temporary fix, pending the release
of libnfc 1.6, which will allow other dependent packages to be progressed in
the interim.
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
