Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: fix minor typo in comments "his own files" -> "its own files"]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The basic rule for a package is to have its options named
after the package name. There is no reason this should not
also be the case for virtual packages.
Besides, this will allow us to switch libegl to use the
soon-to-be-introduced virtual-package infrastructure.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Mike Zick <minimod@morethan.org>
Cc: Samuel Martin <s.martin49@gmail.com>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The basic rule for a package is to have its options named
after the package name. There is no reason this should not
also be the case for virtual packages.
Besides, this will allow us to switch libgles to use the
soon-to-be-introduced virtual-package infrastructure.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Mike Zick <minimod@morethan.org>
Cc: Samuel Martin <s.martin49@gmail.com>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Acked-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
A check for Java has been implemented in dependencies.sh, but during the
review, the name of the variable had been changed from:
BR2_HOST_NEEDS_JAVA to BR2_NEEDS_HOST_JAVA
as it is more accurate.
The change was not made in XBMC and as such, you could start the build
of XBMC without Java on your system.
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Acked-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
XBMC is an award-winning free and open source (GPL) software media
player and entertainment hub for digital media.
We do provide a sub-option for each major feature we support, to avoid
letting the user hunt-down required libraries, since the dependency is
not always obvious and straightforward.
We also provide our own wrapper script, because the ones bundled in
XBMC are not suitable to all platforms. We need such a wrapper script
because XBMC exits with different exit codes, depending on how the user
quit XBMC: 0 is normal exit, 64 is for halt, and 66 is for reboot. So
we can't simply call the real XBMC binary from the startup script, or
we would lose this information. So, we provide a wrapper script that
takes appropriate action according to the above exit codes.
When run as root from a startup script, there is no HOME set, so XBMC
defaults to saving its configuration in /.xbmc (yes, at the root of the
rootfs). Since this does not play well with read-only filesystems (and
is inherently ugly anyway), and sicne there is no real clean way to tell
XBMC where to store its configuration, just provide a symlink to a better
place: /.xbmc -> /var/xbmc (note: the only location _guaranteed_ to be
writable is /tmp, but we want the configuration to survive a reboot. So,
/var/xbmc looks a better place than /var/run/xbmc. and the user will
have to take action to ensure /var/xbmc be writable.) (note: for this
reason, we do not want to set $HOME to /root either, even if it is root
running XBMC.)
Some of XBMC sub-options select libraries that depend on toolchain options,
such as IPv6. But those are already covered, being also implicit
dependencies of XBMC, as XBMC can only be used on an (e)glibc toolchain
anyway. When^WIf XBMC is one day buildable under uClibc/musl, this will be
time to revisit those dependencies.
This package was originally found at : https://github.com/huceke/buildroot-rbp
By gimli <ebsi4711@gmail.com>
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: gimli <ebsi4711@gmail.com>
Cc: Martin Bark <martin@barkynet.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
