Re: [yocto] [meta-raspberrypi][PATCH v2] rpi-config: fix invalid shell variable name
On Tue, 4 Apr 2017 19:35:50 +0200
Andrea Galbusera wrote:
> Commit da32aac introduced an invalid shell variable name in do_deploy():
> according to bash manpage variable names cannot contain dots. Replace
> dot with underscore to fix it.
>
> Signed-off-by: Andrea Galbusera
> ---
>
> v2: also update README accordingly
> Signed-off-by: Andrea Galbusera
> ---
> README | 2 +-
> recipes-bsp/bootfiles/rpi-config_git.bb | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/README b/README
> index c58bc99..9fdd5eb 100644
> --- a/README
> +++ b/README
> @@ -247,7 +247,7 @@ List of currently supported models:
> If you would like to use the Waveshare "C" 1024×600, 7 inch Capacitive Touch
> Screen LCD, HDMI interface (http://www.waveshare.com/7inch-HDMI-LCD-C.htm)
> Rev 2.1, please set the following in your local.conf
> -WAVESHARE_1024X600_C_2.1 = "1"
> +WAVESHARE_1024X600_C_2_1 = "1"
>
> 3.P. Enable UART
> ===
> diff --git a/recipes-bsp/bootfiles/rpi-config_git.bb
> b/recipes-bsp/bootfiles/rpi-config_git.bb
> index 8adc938..af55983 100644
> --- a/recipes-bsp/bootfiles/rpi-config_git.bb
> +++ b/recipes-bsp/bootfiles/rpi-config_git.bb
> @@ -112,7 +112,7 @@ do_deploy() {
> fi
>
> # Waveshare "C" 1024x600 7" Rev2.1 IPS capacitive touch
> (http://www.waveshare.com/7inch-HDMI-LCD-C.htm)
> -if [ "${WAVESHARE_1024X600_C_2.1}" = "1" ]; then
> +if [ "${WAVESHARE_1024X600_C_2_1}" = "1" ]; then
> echo "# Waveshare \"C\" 1024x600 7\" Rev2.1 IPS capacitive touch
> screen" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> echo "max_usb_current=1" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> echo "hdmi_group=2" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
This fixes the build for me and looks good :)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH v2] logrotate: Add systemd support
ping
Le 24/03/2017 à 09:46, Romain Perier a écrit :
> Currently, this recipe only supports daily scheduling via a cron job.
> This commit adds support for systemd, including systemd service and
> systemd timer. When the corresponding distro feature is enabled the
> systemd variant will be used. The timer granularity and its accuracy
> are also configurable.
>
> Signed-off-by: Romain Perier
> ---
>
> Changes in v2:
> - Make the systemd timer configurable (as this is distribution or target
> specific)
>
> .../logrotate/logrotate/logrotate.service | 9
> .../logrotate/logrotate/logrotate.timer| 7 ++
> meta/recipes-extended/logrotate/logrotate_3.9.1.bb | 27
> --
> 3 files changed, 41 insertions(+), 2 deletions(-)
> create mode 100644
> meta/recipes-extended/logrotate/logrotate/logrotate.service
> create mode 100644 meta/recipes-extended/logrotate/logrotate/logrotate.timer
>
> diff --git a/meta/recipes-extended/logrotate/logrotate/logrotate.service
> b/meta/recipes-extended/logrotate/logrotate/logrotate.service
> new file mode 100644
> index 000..3edb8ef
> --- /dev/null
> +++ b/meta/recipes-extended/logrotate/logrotate/logrotate.service
> @@ -0,0 +1,9 @@
> +[Unit]
> +Description=Rotate log files
> +
> +[Service]
> +Type=oneshot
> +ExecStart=/usr/sbin/logrotate /etc/logrotate.conf
> +Nice=19
> +IOSchedulingClass=best-effort
> +IOSchedulingPriority=7
> diff --git a/meta/recipes-extended/logrotate/logrotate/logrotate.timer
> b/meta/recipes-extended/logrotate/logrotate/logrotate.timer
> new file mode 100644
> index 000..c616b43
> --- /dev/null
> +++ b/meta/recipes-extended/logrotate/logrotate/logrotate.timer
> @@ -0,0 +1,7 @@
> +[Unit]
> +Description=Daily rotation of log files
> +
> +[Timer]
> +OnCalendar=@TIMER_BASIS@
> +AccuracySec=@TIMER_ACCURACY@
> +Persistent=true
> diff --git a/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
> b/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
> index 5f1a601..6953996 100644
> --- a/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
> +++ b/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
> @@ -14,6 +14,8 @@ SRC_URI =
> "https://fedorahosted.org/releases/l/o/logrotate/logrotate-${PV}.tar.g
> file://act-as-mv-when-rotate.patch \
> file://update-the-manual.patch \
> file://disable-check-different-filesystems.patch \
> + ${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
> 'file://logrotate.service', '', d)} \
> + ${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
> 'file://logrotate.timer', '', d)} \
> "
>
> SRC_URI[md5sum] = "4492b145b6d542e4a2f41e77fa199ab0"
> @@ -47,6 +49,17 @@ EXTRA_OEMAKE = "\
> # INSTALL=install and BASEDIR=/usr.
> OS_NAME = "Linux"
>
> +inherit systemd
> +
> +SYSTEMD_AUTO_ENABLE = "disable"
> +SYSTEMD_SERVICE_${PN} = "\
> +${PN}.service \
> +${PN}.timer \
> +"
> +
> +LOGROTATE_SYSTEMD_TIMER_BASIS ?= "daily"
> +LOGROTATE_SYSTEMD_TIMER_ACCURACY ?= "12h"
> +
> do_compile_prepend() {
> # Make sure the recompile is OK
> rm -f ${B}/.depend
> @@ -55,9 +68,19 @@ do_compile_prepend() {
> do_install(){
> oe_runmake install DESTDIR=${D} PREFIX=${D} MANDIR=${mandir}
> mkdir -p ${D}${sysconfdir}/logrotate.d
> -mkdir -p ${D}${sysconfdir}/cron.daily
> mkdir -p ${D}${localstatedir}/lib
> install -p -m 644 examples/logrotate-default
> ${D}${sysconfdir}/logrotate.conf
> -install -p -m 755 examples/logrotate.cron
> ${D}${sysconfdir}/cron.daily/logrotate
> touch ${D}${localstatedir}/lib/logrotate.status
> +
> +# Install systemd unit files
> +if [ "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '',
> d)}" = "systemd" ]; then
> +install -d ${D}/${systemd_system_unitdir}
> +install -m 0644 ${WORKDIR}/logrotate.service
> ${D}/${systemd_system_unitdir}/logrotate.service
> +install -m 0644 ${WORKDIR}/logrotate.timer
> ${D}/${systemd_system_unitdir}/logrotate.timer
> +sed -i -e 's,@TIMER_BASIS@,${LOGROTATE_SYSTEMD_TIMER_BASIS},g'
> ${D}${systemd_system_unitdir}/logrotate.timer
> +sed -i -e 's,@TIMER_ACCURACY@,${LOGROTATE_SYSTEMD_TIMER_ACCURACY},g'
> ${D}${systemd_system_unitdir}/logrotate.timer
> +else
> +mkdir -p ${D}${sysconfdir}/cron.daily
> +install -p -m 0755 examples/logrotate.cron
> ${D}${sysconfdir}/cron.daily/logrotate
> +fi
> }
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] FIT Image boot issue
Hello all, We are using FIT image in an ARM 64 bit target based instead of separate Linux binary(Image.bin) and DTB. We are using a copy of the kernel fit image bbclass provided by poky in our custom machine layer to build the fit image. We observe that the bootloader is not able to load the device tree from the RAM. We are using Yocto project 2.1 and kernel version 4.9 Additionally, we observe that the fit image size varies across builds. We are observing two different image sizes viz 6855936 and 6855932 bytes. Of these two, the fit image with size 6855932 bytes boot properly while the image with size 6855936 doesn't boot. Most often the image with 6855932 bytes is generated as build output. Out of 5 to 7 builds (approximately), the image with size 6855936 bytes that causes the boot issue is generated once. We had modified our custom machine conf file and the kernel-fitimage.bbclass provided by poky layer for adding fit Image support . I have attached the modified fitimage bbclass file,our custom machine layer conf file ,its file generated and the error log during boot for your reference. Regards, Hari Prasath fit-image-error.log Description: fit-image-error.log fitImage-its-salvator-x.its Description: fitImage-its-salvator-x.its kernel-fitimage.bbclass Description: kernel-fitimage.bbclass salvator-x.conf Description: salvator-x.conf -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FIT Image boot issue
Hi, Did you try if it works out of yocto? I use those lines to generate FitImage from a kernel tree: source ../poky/build/tmp/environment-setup-cortexa8hf-neon-helix-linux-gnueabi make ARCH=arm CROSS_COMPILE=arm-helix-linux-gnueabi- -j16 zImage ???.dtb ???.dtb arm-helix-linux-gnueabi-objcopy -O binary -R .note -R .comment -S arch/arm/boot/compressed/vmlinux linux.bin mkimage -f ???.its fitImage Fabien On Tue, 2017-04-04 at 14:08 +, Gujulan Elango, Hari Prasath (H.) wrote: > Hello all, > > We are using FIT image in an ARM 64 bit target based instead of separate > Linux binary(Image.bin) > and DTB. We are using a copy of the kernel fit image bbclass provided by poky > in our custom > machine layer to build the fit image. We observe that the bootloader is not > able to load the > device tree from the RAM. We are using Yocto project 2.1 and kernel version > 4.9 > > Additionally, we observe that the fit image size varies across builds. We are > observing two > different image sizes viz 6855936 and 6855932 bytes. Of these two, the fit > image with size 6855932 > bytes boot properly while the image with size 6855936 doesn't boot. Most > often the image with > 6855932 bytes is generated as build output. Out of 5 to 7 builds > (approximately), the image with > size 6855936 bytes that causes the boot issue is generated once. > > We had modified our custom machine conf file and the kernel-fitimage.bbclass > provided by poky > layer for adding fit Image support . I have attached the modified fitimage > bbclass file,our custom > machine layer conf file ,its file generated and the error log during boot for > your reference. > > Regards, > Hari Prasath > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [[PATCH][yocto-autobuilder]] nightly-oe-selftest.conf: Remove set of SANITY_TESTED_DISTROS
On Tue, 2017-04-04 at 12:18 -0500, Aníbal Limón wrote:
> The sanity testing was disabled for all builds into CreateAutoConf
> buildstep so atextappend isn't need now. [1]
Thanks for catching this, pushed to master.
Joshua
> [1] http://git.yoctoproject.org/cgit/cgit.cgi/yocto-
> autobuilder/commit/?id=87b10595e9a1d36081ec60d3069f4a98798f27eb
>
> Signed-off-by: Aníbal Limón
> ---
> buildset-config.controller/nightly-oe-selftest.conf | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/buildset-config.controller/nightly-oe-selftest.conf
> b/buildset-config.controller/nightly-oe-selftest.conf
> index a267516..fb401de 100644
> --- a/buildset-config.controller/nightly-oe-selftest.conf
> +++ b/buildset-config.controller/nightly-oe-selftest.conf
> @@ -11,7 +11,6 @@ steps: [{'SetDest':{}},
> {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' :
> 'x86_64',
> 'distro': 'poky', 'nosstate': True,
> 'packages': 'rpm', 'buildhistory' :
> False,
> -'atextappend':
> '\nSANITY_TESTED_DISTROS=""',
> 'prserv': False}},
> {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
> {'BuildImages': {'images': 'core-image-minimal'}},
> --
> 2.1.4
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCH v2] logrotate: Add systemd support
Add yocto and Alexander to Cc: (sorry) Romain Le 05/04/2017 à 11:30, Romain Perier a écrit : > Hello, > > > Le 05/04/2017 à 10:25, Alexander Kanavin a écrit : >> On 04/05/2017 10:58 AM, Romain Perier wrote: >>> ping >>> >> Is this available in newer upstream versions of logrotate? Should you >> send it there first? >> >> Alex >> > No, not yet. > Mhhh, we have variables specific to the recipe in the .service and > .timer, but I think that I can still send a generic version of these > files on upstream and use sed anyway from the recipe... > > Romain -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Install rootfs.tar.bz2 to ${D}/home/root/
Hi,
I want to create a deployable SD card image. My board (beaglebone based) boots
from SD card and runs a script which copies the rootfs.tar.bz2 to the flash
memory.
So how can I deploy a copy of the whole rootfs to ${D}/home/root?
A rootfs in the rootfs, does that make sense?
Any help is appreciated.
Chris
i.A. Chris Maier
Software-Entwicklungsingenieur
Phone: +49 7152 203 6741 | Fax: +49 7152 203 76741 | c.ma...@geze.com
GEZE GmbH, Reinhold-Vöster-Straße 21-29, 71229 Leonberg | www.geze.com
SAVE PAPER - THINK BEFORE YOU PRINT
Geschäftsführung: Brigitte Vöster-Alber (Vorsitzende), Andrea
Alexandra Alber, Marc Alber, Florian Birkenmayer
Vorsitzender des Aufsichtsrates: Prof. Dr. Dr. Ulli Arnold, Amtsgericht
Stuttgart HRB 250329, Tel: +49 7152 203 0
GEZE GmbH, Reinhold-Vöster-Straße 21-29, 71229 Leonberg, Germany
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] iMX6UL - QtQuick - QtQuick2DRenderer
Hi all,
I'm trying to run a graphical Qt application based in QtQuick2 and QML
(example calqtr) in my iMX6UL (Variscite's Dart6UL). As this device
doesn't have GPU, I have to use QtQuick2DRenderer to substitute openGL.
I'm using Ubuntu 14.04 64bits and Krogoth 2.1.2
I have the enterprise license, followed the Qt's instructions
(http://doc.qt.io/QtQuick2DRenderer/qtquick2drenderer-installation-guide.html)
and use the qmake built with meta-toolchain-qt5. So QtQuick2DRenderer is
correctly installed.
Then, before run the app, I declared export
QMLSCENE_DEVICE=softwarecontext before running the application.
Unfortunately, I get the next message when try to run a demo example:
./calqlatr --platform linuxfb
QML debugging is enabled. Only use this in a safe environment.
This plugin does not support createPlatformOpenGLContext!
Failed to create OpenGL context for format QSurfaceFormat(version 2.0,
options QFlags(), depthBufferSize 24, redBufferSize -1, greenBufferSize
-1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples
-1, swapBehavior 2, swapInterval 1, profile 0)
Aborted (core dumped)
I did the SDK using meta-toolchain-qt5 and the image with fsl-image-qt5.
When I run a console app or a graphical which uses QtQuick 1, it works
correctly.
This is my conf/local.conf file:
MACHINE ??= 'imx6ul-var-dart'
DISTRO ?= 'fsl-imx-fb'
PACKAGE_CLASSES ?= "package_rpm"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
USER_CLASSES ?= "buildstats image-mklibs"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS = "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
STOPTASKS,/tmp,100M,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K \
ABORT,/tmp,10M,1K"
PACKAGECONFIG_append_pn-qemu-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
CONF_VERSION = "1"
DL_DIR ?= "${BSPDIR}/downloads/"
ACCEPT_FSL_EULA = "1"
# Add Eclipse debug and Qt creator support to your images
EXTRA_IMAGE_FEATURES = " \
debug-tweaks \
tools-debug \
eclipse-debug \
"
IMAGE_INSTALL_append = " \
tcf-agent \
openssh-sftp-server \
qtbase-fonts \
qtbase-plugins \
qtbase-tools \
qtbase-examples \
qtdeclarative \
qtdeclarative-plugins \
qtdeclarative-tools \
qtdeclarative-examples \
qtdeclarative-qmlplugins \
qtquickcontrols-qmlplugins \
"
# Use systemd instead of SysV init
DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscripts = ""
IMX_DEFAULT_DISTRO_FEATURES_append = " systemd"
I think, that problem could be in configuring -opengl es2 in qtbase
recipe. But when I set it manually I get errors doing bitbake
fsl-image-qt5
Este correo electrónico y sus documentos adjuntos contienen información
privilegiada, personal y estrictamente confidencial, y está prohibida la copia,
reenvío o utilización de la información.
Si usted no es la persona destinataria del presente mensaje, no está autorizada
a leerlo, retenerlo o difundirlo.
This e-mail and its attachments are privileged, confidential and contain
private information, and any sending, using or copy of its information is
prohibited.
Any person other than its intended recipient is not authorised to read, retain
or distribute this information.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Install rootfs.tar.bz2 to ${D}/home/root/
On Wed, 2017-04-05 at 11:21 +, Maier, Chris wrote:
> Hi,
>
> I want to create a deployable SD card image. My board (beaglebone based)
> boots from SD card and
> runs a script which copies the rootfs.tar.bz2 to the flash memory.
> So how can I deploy a copy of the whole rootfs to ${D}/home/root?
> A rootfs in the rootfs, does that make sense?
I don't think it is good if both rootfs are based on the same image.
>
> Any help is appreciated.
>
My first idea will be to create an install image for sd card depending on your
image rootfs tarball.
$ cat installer-image.bb
...
do_rootfs[depends] += "original-image"
ROOTFS_POSTPROCESS_COMMAND = my-copy-image-to-installer-rootfs
my-copy-image-to-installer-rootfs() {
cp ??.tar.bz2 ${D}/home/root
}
But maybe it is not the best solution.
You can look at meta/classes/image-live.bbclass which provides a similar
mechanism.
>
> Chris
> i.A. CHRIS MAIER
> Software-Entwicklungsingenieur
>
> Phone: +49 7152 203 6741 | Fax: +49 7152 203 76741 | c.ma...@geze.com
> GEZE GmbH, Reinhold-Vöster-Straße 21-29, 71229 Leonberg | www.geze.com
>
> SAVE PAPER - THINK BEFORE YOU PRINT
> Geschäftsführung: Brigitte Vöster-Alber (Vorsitzende),
> Andrea Alexandra
> Alber, Marc Alber, Florian Birkenmayer
> Vorsitzender des Aufsichtsrates: Prof. Dr. Dr. Ulli Arnold, Amtsgericht
> Stuttgart HRB 250329, Tel:
> +49 7152 203 0
> GEZE GmbH, Reinhold-Vöster-Straße 21-29, 71229 Leonberg, Germany
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Install rootfs.tar.bz2 to ${D}/home/root/
On 05-04-17 13:21, Maier, Chris wrote:
Hi,
I want to create a deployable SD card image. My board (beaglebone based) boots
from SD card and runs a script which copies the rootfs.tar.bz2 to the flash
memory.
So how can I deploy a copy of the whole rootfs to ${D}/home/root?
A rootfs in the rootfs, does that make sense?
I do it like this:
http://lists.openembedded.org/pipermail/openembedded-core/2017-April/135187.html
The idea is that you make a regular package that contains the tar.bz2 of the
image you want in flash and put that into the image for the SD card.
You cannot have the same image, since that would recursively include itself,
but you could make big-image.bb like this:
require small-image.bb
IMAGE_INSTALL += "big-project"
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCH v2] logrotate: Add systemd support
I have just realized, systemd service and timer is already present and supported on upstream (like cron, in examples/). At least in 3.11.0 and master. I will propose an update of this recipe to 3.11.0 (the last release) and then add support for systemd. Regards, Romain Le 05/04/2017 à 11:41, Romain Perier a écrit : > Add yocto and Alexander to Cc: (sorry) > > Romain > > > Le 05/04/2017 à 11:30, Romain Perier a écrit : >> Hello, >> >> >> Le 05/04/2017 à 10:25, Alexander Kanavin a écrit : >>> On 04/05/2017 10:58 AM, Romain Perier wrote: ping >>> Is this available in newer upstream versions of logrotate? Should you >>> send it there first? >>> >>> Alex >>> >> No, not yet. >> Mhhh, we have variables specific to the recipe in the .service and >> .timer, but I think that I can still send a generic version of these >> files on upstream and use sed anyway from the recipe... >> >> Romain -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] GNU/Octave
Dears, do you know is there recipe for GNU/Octave " https://www.gnu.org/software/octave/";? Is it possible to get it running on Yocto/Linux machine? Thanks. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] GNU/Octave
hello On Wed, 2017-04-05 at 14:45 +0200, Peter Balazovic wrote: > Dears, > > do you know is there recipe for GNU/Octave > "https://www.gnu.org/software/octave/";? > Is it possible to get it running on Yocto/Linux machine? > A quick google search return this : https://github.com/openembedded/openembedded/tree/master/recipes/octave So it seems possible to make it running. > Thanks. > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [extensible_SDK] meta-world-pkgdata fails due to unresolvable RDEPEND statements
When trying to build the extensible sdk with 'bitbake -c populate_sdk_ext
' and these settings in my local.conf:
SDK_TITLE = "CAS_Extensible_SDK"
SDK_EXT_TYPE = "minimal"
SDK_INCLUDE_PKGDATA = "1"
SDK_INCLUDE_TOOLCHAIN = "0"
Bitbake is trying to build the 'meta-world-pkgdata' target. This would be
fine, however I get a lot of errors regarding
missing or unbuildable dependencys due to some unresolvable RDEPENDS
statements.
(e.g.: ERROR: Nothing RPROVIDES 'libgles2' (but
/local.build/nightly/poky_h3/build_h3/../poky/meta/recipes-graphics/cogl/cogl-1.0_1.22.0.bb
RDEPENDS on or otherwise requires it))
I tried to mask some recipes with the EXCLUDE_FROM_WORLD variable (in the
above case: for cogl) but after 20 recipes and still the same errors I
stopped.
If I build the SDK with 'SDK_INCLUDE_PKGDATA = "0" ' it works fine but I
do not get package index.
I also tried to find the missing recipes for the RDEPENDS but they are not
in any of my used layers.
Is there a way restrict the 'meta-world-pkgdata' target to a certain
layer? It would be sufficient for me if the package index would be created
only for my custom layer.
If not, is there a way to systematically resolve the RDEPENDS issues?
Where to start here?
I'm using krogoth together with the meta-renesas layer and some project
specific custom layers. I also tried building the SDK for
'core-image-minimal' with the same result.
Here is the content of my bblayers.conf:
POKY_BBLAYERS_CONF_VERSION = "2"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS ?= " \
${TOPDIR}/../poky/meta \
${TOPDIR}/../poky/meta-poky \
${TOPDIR}/../poky/meta-yocto-bsp \
${TOPDIR}/../meta-renesas/meta-rcar-gen3 \
${TOPDIR}/../meta-linaro/meta-optee \
${TOPDIR}/../meta-linaro/meta-linaro-toolchain \
${TOPDIR}/../meta-openembedded/meta-oe \
${TOPDIR}/../CAS_platform \
${TOPDIR}/../tf-apd/yocto-layers/meta-ara \
${TOPDIR}/../cas-applications/CAS_application \
"
BBLAYERS_NON_REMOVABLE ?= " \
${TOPDIR}/../poky/meta \
${TOPDIR}/../poky/meta-poky \
"
It would be very nice if someone could point me in the right direction. At
the moment I just ran out of ideas how to proceed.
With kind regards
Sven Woelfel
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] GNU/Octave
On Wed, Apr 5, 2017 at 9:22 AM, Fabien Lahoudere wrote: > On Wed, 2017-04-05 at 14:45 +0200, Peter Balazovic wrote: >> do you know is there recipe for GNU/Octave >> "https://www.gnu.org/software/octave/";? >> Is it possible to get it running on Yocto/Linux machine? In general, when looking for a recipe a good place to start is the layer index: https://layers.openembedded.org After that, google is the next place to try :-) > A quick google search return this : > https://github.com/openembedded/openembedded/tree/master/recipes/octave That recipe comes for the "openembedded *classic*" repository, which was abandoned years ago. So it might work, or it might needs lots of tweaking to get it to work, or it might need to be rewritten. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] GNU/Octave
You can write a new recipe using https://github.com/openembedded/openembedded/tree/master/recipes/octave as a start point, and also see gentoo ebuild to check runtime depends or get some inspiration :) https://gitweb.gentoo.org/repo/gentoo.git/tree/sci-mathematics/octave/octave-4.2.1.ebuild On 04/05/2017 10:38 AM, Trevor Woerner wrote: On Wed, Apr 5, 2017 at 9:22 AM, Fabien Lahoudere wrote: On Wed, 2017-04-05 at 14:45 +0200, Peter Balazovic wrote: do you know is there recipe for GNU/Octave "https://www.gnu.org/software/octave/";? Is it possible to get it running on Yocto/Linux machine? In general, when looking for a recipe a good place to start is the layer index: https://layers.openembedded.org After that, google is the next place to try :-) A quick google search return this : https://github.com/openembedded/openembedded/tree/master/recipes/octave That recipe comes for the "openembedded *classic*" repository, which was abandoned years ago. So it might work, or it might needs lots of tweaking to get it to work, or it might need to be rewritten. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/2] logrotate: systemd support
SystemD is now supported by upstream logrotate. This set of patches first bumps the recipe to the last upstream version, that is 3.11.0. Then it adds support for systemd. This series is the continuety of the following patch: 1. https://lists.yoctoproject.org/pipermail/yocto/2017-March/035277.html Note: The default SRC_URI to be used for tarball is still under discussion on the ML. Do we use github or downloads.yoctoproject.org ? How do we upload the tarball ? Romain Perier (2): logrotate: Bump to 3.11.0 logrotate: Add systemd support .../recipes-extended/logrotate/logrotate_3.11.0.bb | 78 ++ meta/recipes-extended/logrotate/logrotate_3.9.1.bb | 60 - 2 files changed, 78 insertions(+), 60 deletions(-) create mode 100644 meta/recipes-extended/logrotate/logrotate_3.11.0.bb delete mode 100644 meta/recipes-extended/logrotate/logrotate_3.9.1.bb -- 2.9.3 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2] logrotate: Bump to 3.11.0
This commit updates the recipe to the last upstream tag. Then, as the
tarball no longer contains the pre-generated Makefile, inherit from
autotools
Signed-off-by: Romain Perier
---
.../{logrotate_3.9.1.bb => logrotate_3.11.0.bb}| 23 +++---
1 file changed, 11 insertions(+), 12 deletions(-)
rename meta/recipes-extended/logrotate/{logrotate_3.9.1.bb =>
logrotate_3.11.0.bb} (69%)
diff --git a/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
b/meta/recipes-extended/logrotate/logrotate_3.11.0.bb
similarity index 69%
rename from meta/recipes-extended/logrotate/logrotate_3.9.1.bb
rename to meta/recipes-extended/logrotate/logrotate_3.11.0.bb
index 9c2dfe0..d72c7f0 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.11.0.bb
@@ -3,23 +3,25 @@ SECTION = "console/utils"
HOMEPAGE = "https://fedorahosted.org/logrotate/";
LICENSE = "GPLv2"
-# TODO: logrotate 3.8.8 adds autotools/automake support, update recipe to use
it.
# TODO: Document coreutils dependency. Why not RDEPENDS? Why not busybox?
DEPENDS="coreutils popt"
LIC_FILES_CHKSUM = "file://COPYING;md5=18810669f13b87348459e611d31ab760"
-SRC_URI =
"https://fedorahosted.org/releases/l/o/logrotate/logrotate-${PV}.tar.gz \
+# TODO: We need to decide if we github or downloads.yoctoproject.org
+SRC_URI =
"https://github.com/logrotate/logrotate/releases/download/${PV}/logrotate-${PV}.tar.gz
\
file://act-as-mv-when-rotate.patch \
file://update-the-manual.patch \
file://disable-check-different-filesystems.patch \
"
+SRC_URI[md5sum] = "15db4027b07b3e239297e4c87c6da2e9"
+SRC_URI[sha256sum] =
"7dcb440ed2f1937459e1e06f841c6af1e564b77b2df8009147b56c8649197910"
-SRC_URI[md5sum] = "4492b145b6d542e4a2f41e77fa199ab0"
-SRC_URI[sha256sum] =
"022769e3288c80981559a8421703c88e8438b447235e36dd3c8e97cd94c52545"
-
-PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'acl selinux', d)}"
+PACKAGECONFIG ?= "\
+${@bb.utils.contains('DISTRO_FEATURES', 'acl', 'acl', '', d)} \
+${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux', '', d)} \
+"
PACKAGECONFIG[acl] = ",,acl"
PACKAGECONFIG[selinux] = ",,libselinux"
@@ -44,17 +46,14 @@ EXTRA_OEMAKE = "\
# INSTALL=install and BASEDIR=/usr.
OS_NAME = "Linux"
-do_compile_prepend() {
-# Make sure the recompile is OK
-rm -f ${B}/.depend
-}
+inherit autotools
do_install(){
oe_runmake install DESTDIR=${D} PREFIX=${D} MANDIR=${mandir}
mkdir -p ${D}${sysconfdir}/logrotate.d
mkdir -p ${D}${sysconfdir}/cron.daily
mkdir -p ${D}${localstatedir}/lib
-install -p -m 644 examples/logrotate-default
${D}${sysconfdir}/logrotate.conf
-install -p -m 755 examples/logrotate.cron
${D}${sysconfdir}/cron.daily/logrotate
+install -p -m 644 ${S}/examples/logrotate-default
${D}${sysconfdir}/logrotate.conf
+install -p -m 755 ${S}/examples/logrotate.cron
${D}${sysconfdir}/cron.daily/logrotate
touch ${D}${localstatedir}/lib/logrotate.status
}
--
2.9.3
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2] logrotate: Add systemd support
Currently, this recipe only supports daily scheduling via a cron job.
This commit adds support for systemd in the recipe, as the feature is
already supported on upstream. When the corresponding distro feature
is enabled the systemd variant will be used. The timer granularity and
its accuracy are also configurable.
Signed-off-by: Romain Perier
---
.../recipes-extended/logrotate/logrotate_3.11.0.bb | 25 +++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-extended/logrotate/logrotate_3.11.0.bb
b/meta/recipes-extended/logrotate/logrotate_3.11.0.bb
index d72c7f0..b75496d 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.11.0.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.11.0.bb
@@ -46,14 +46,33 @@ EXTRA_OEMAKE = "\
# INSTALL=install and BASEDIR=/usr.
OS_NAME = "Linux"
-inherit autotools
+inherit autotools systemd
+
+SYSTEMD_AUTO_ENABLE = "disable"
+SYSTEMD_SERVICE_${PN} = "\
+${PN}.service \
+${PN}.timer \
+"
+
+LOGROTATE_SYSTEMD_TIMER_BASIS ?= "daily"
+LOGROTATE_SYSTEMD_TIMER_ACCURACY ?= "12h"
do_install(){
oe_runmake install DESTDIR=${D} PREFIX=${D} MANDIR=${mandir}
mkdir -p ${D}${sysconfdir}/logrotate.d
-mkdir -p ${D}${sysconfdir}/cron.daily
mkdir -p ${D}${localstatedir}/lib
install -p -m 644 ${S}/examples/logrotate-default
${D}${sysconfdir}/logrotate.conf
-install -p -m 755 ${S}/examples/logrotate.cron
${D}${sysconfdir}/cron.daily/logrotate
touch ${D}${localstatedir}/lib/logrotate.status
+
+# Install systemd unit files
+if [ "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '',
d)}" = "systemd" ]; then
+install -d ${D}${systemd_system_unitdir}
+install -m 0644 ${S}/examples/logrotate.service
${D}${systemd_system_unitdir}/logrotate.service
+install -m 0644 ${S}/examples/logrotate.timer
${D}${systemd_system_unitdir}/logrotate.timer
+sed -i -e
's,OnCalendar=.*$,OnCalendar=${LOGROTATE_SYSTEMD_TIMER_BASIS},g'
${D}${systemd_system_unitdir}/logrotate.timer
+sed -i -e
's,AccuracySec=.*$,AccuracySec=${LOGROTATE_SYSTEMD_TIMER_ACCURACY},g'
${D}${systemd_system_unitdir}/logrotate.timer
+else
+mkdir -p ${D}${sysconfdir}/cron.daily
+install -p -m 0755 ${S}/examples/logrotate.cron
${D}${sysconfdir}/cron.daily/logrotate
+fi
}
--
2.9.3
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] rpi-config: waveshare screen support
On Tue, Apr 04, 2017 at 06:10:57PM -0400, Trevor Woerner wrote: > I see what happened... knowing that I needed those lines set, my > bbappend didn't have the "if" line, it simply applied the lines > without the check. The check was added when pushing upstream just in > case somebody didn't want those lines in their config :-) I should > have tested more extensively after adding the line. > > Sorry! It happens. Don't worry about it. -- Andrei Gherzan gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH v2] rpi-config: fix invalid shell variable name
On Tue, Apr 04, 2017 at 07:35:50PM +0200, Andrea Galbusera wrote:
> Commit da32aac introduced an invalid shell variable name in do_deploy():
> according to bash manpage variable names cannot contain dots. Replace
> dot with underscore to fix it.
>
> Signed-off-by: Andrea Galbusera
> ---
>
> v2: also update README accordingly
> Signed-off-by: Andrea Galbusera
> ---
> README | 2 +-
> recipes-bsp/bootfiles/rpi-config_git.bb | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/README b/README
> index c58bc99..9fdd5eb 100644
> --- a/README
> +++ b/README
> @@ -247,7 +247,7 @@ List of currently supported models:
> If you would like to use the Waveshare "C" 1024×600, 7 inch Capacitive Touch
> Screen LCD, HDMI interface (http://www.waveshare.com/7inch-HDMI-LCD-C.htm)
> Rev 2.1, please set the following in your local.conf
> -WAVESHARE_1024X600_C_2.1 = "1"
> +WAVESHARE_1024X600_C_2_1 = "1"
>
> 3.P. Enable UART
> ===
> diff --git a/recipes-bsp/bootfiles/rpi-config_git.bb
> b/recipes-bsp/bootfiles/rpi-config_git.bb
> index 8adc938..af55983 100644
> --- a/recipes-bsp/bootfiles/rpi-config_git.bb
> +++ b/recipes-bsp/bootfiles/rpi-config_git.bb
> @@ -112,7 +112,7 @@ do_deploy() {
> fi
>
> # Waveshare "C" 1024x600 7" Rev2.1 IPS capacitive touch
> (http://www.waveshare.com/7inch-HDMI-LCD-C.htm)
> -if [ "${WAVESHARE_1024X600_C_2.1}" = "1" ]; then
> +if [ "${WAVESHARE_1024X600_C_2_1}" = "1" ]; then
> echo "# Waveshare \"C\" 1024x600 7\" Rev2.1 IPS capacitive touch
> screen" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> echo "max_usb_current=1" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> echo "hdmi_group=2" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> --
> 2.7.4
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
Merged to master. Thanks.
--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan
signature.asc
Description: PGP signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] wiringpi: uprev to 2.44
On Mon, Apr 03, 2017 at 10:07:27PM +0200, Andrea Galbusera wrote: > This upgrade is required to solve the following runtime hardware detection > issue when calling wiringPiSetup() on the Pi3: > > Unable to determine hardware version. I see: Hardware : BCM2835 > , > - expecting BCM2708 or BCM2709. > > This was triggered by the recent kernel upgrade to 4.9 that introduced > "BCM2835" as the hardware signature in /proc/cpuinfo. > > Patches reworked as follow: > * 0001-Add-initial-cross-compile-support.patch: rebase to current upstream > * 0001-include-asm-ioctl.h-directly-for-_IOC_SIZEBITS.patch: drop since is now > upstream > > Signed-off-by: Andrea Galbusera > --- > .../0001-Add-initial-cross-compile-support.patch | 96 > +++--- > ...de-asm-ioctl.h-directly-for-_IOC_SIZEBITS.patch | 58 - > recipes-devtools/wiringPi/wiringpi_git.bb | 5 +- > 3 files changed, 51 insertions(+), 108 deletions(-) > delete mode 100644 > recipes-devtools/wiringPi/wiringpi/0001-include-asm-ioctl.h-directly-for-_IOC_SIZEBITS.patch > > diff --git > a/recipes-devtools/wiringPi/files/0001-Add-initial-cross-compile-support.patch > > b/recipes-devtools/wiringPi/files/0001-Add-initial-cross-compile-support.patch > index 603422c..a081b8d 100644 > --- > a/recipes-devtools/wiringPi/files/0001-Add-initial-cross-compile-support.patch > +++ > b/recipes-devtools/wiringPi/files/0001-Add-initial-cross-compile-support.patch > @@ -1,21 +1,26 @@ > -From 6d85e6cc3ab97c3f060e5e0a8e3f1945a14c86ba Mon Sep 17 00:00:00 2001 > -From: Gianfranco Costamagna > -Date: Mon, 12 Oct 2015 12:15:51 +0200 > -Subject: [PATCH] Add initial cross compile support (rebase from Petter > Mabäcker version) > +From 4ed727aa9e528f130fdc8798df771037a1f22fc9 Mon Sep 17 00:00:00 2001 > +From: Andrea Galbusera > +Date: Mon, 3 Apr 2017 14:48:14 +0200 > +Subject: [PATCH] =?UTF-8?q?Add=20initial=20cross=20compile=20support=20(re?= > + =?UTF-8?q?base=20from=20Petter=20Mab=C3=A4cker=20=20ve?= > + =?UTF-8?q?rsion)?= > +MIME-Version: 1.0 > +Content-Type: text/plain; charset=UTF-8 > +Content-Transfer-Encoding: 8bit > > --- > - devLib/Makefile | 54 > --- > - examples/Gertboard/Makefile | 22 +++--- > - examples/Makefile | 22 +++--- > - examples/PiFace/Makefile| 22 +++--- > - examples/PiGlow/Makefile|4 ++-- > - examples/q2w/Makefile |4 ++-- > - gpio/Makefile | 29 --- > - wiringPi/Makefile | 50 +-- > - 8 files changed, 119 insertions(+), 88 deletions(-) > + devLib/Makefile | 54 > + > + examples/Gertboard/Makefile | 20 +++-- > + examples/Makefile | 20 +++-- > + examples/PiFace/Makefile| 20 +++-- > + examples/PiGlow/Makefile| 4 ++-- > + examples/q2w/Makefile | 4 ++-- > + gpio/Makefile | 29 > + wiringPi/Makefile | 50 +++-- > + 8 files changed, 116 insertions(+), 85 deletions(-) > > diff --git a/devLib/Makefile b/devLib/Makefile > -index 0fb0033..cbea759 100644 > +index cf665d6..040c03a 100644 > --- a/devLib/Makefile > +++ b/devLib/Makefile > @@ -31,15 +31,19 @@ ifneq ($V,1) > @@ -46,7 +51,7 @@ index 0fb0033..cbea759 100644 > > LIBS= > > -@@ -66,16 +70,16 @@ $(STATIC): $(OBJ) > +@@ -68,16 +72,16 @@ $(STATIC): $(OBJ) > > $(DYNAMIC): $(OBJ) > $Q echo "[Link (Dynamic)]" > @@ -66,7 +71,7 @@ index 0fb0033..cbea759 100644 > > .PHONY: tags > tags: $(SRC) > -@@ -86,22 +90,22 @@ tags:$(SRC) > +@@ -88,22 +92,22 @@ tags:$(SRC) > .PHONY: install > install:$(DYNAMIC) > $Q echo "[Install Headers]" > @@ -99,7 +104,7 @@ index 0fb0033..cbea759 100644 > > .PHONY: install-deb > install-deb:$(DYNAMIC) > -@@ -116,9 +120,11 @@ install-deb:$(DYNAMIC) > +@@ -118,9 +122,11 @@ install-deb:$(DYNAMIC) > .PHONY: uninstall > uninstall: > $Q echo "[UnInstall]" > @@ -127,12 +132,11 @@ index 1939ad6..98d1415 100644 > -CC = gcc > -INCLUDE = -I/usr/local/include > -CFLAGS = $(DEBUG) -Wall $(INCLUDE) -Winline -pipe > -- > --LDFLAGS = -L/usr/local/lib > --LDLIBS= -lwiringPi -lwiringPiDev -lpthread -lm > +DESTDIR?=/usr > +PREFIX?=/local > -+ > + > +-LDFLAGS = -L/usr/local/lib > +-LDLIBS= -lwiringPi -lwiringPiDev -lpthread -lm > +INCLUDE_DIR?=$(DESTDIR)$(PREFIX)/include > +LIB_DIR?=$(DESTDIR)$(PREFIX)/lib > + > @@ -148,7 +152,7 @@ index 1939ad6..98d1415 100644 > # Should not alter anything below this line > > ### > diff --git a/examples/Makefile b/examples/Makefile > -index e6b9b71..931b167 100644 > +index 6d87885..8623816 100644 > --- a/examp
[yocto] [patchwork][PATCH v2] create-pull-request: add "-t in-reply-to" option
The create-pull-request script creates patches as replies to a cover
letter, in the form of an email thread. If further revisions are sent to
the mailing list without referencing to the first revision, these new
revisions are not identified at the mailing list as part of the original
thread, but as a new thread instead.
This change adds the "[-t in_reply_to]" option, where "in_reply_to" is
the original cover letter's Message-Id, so this reference is added
to the new cover letter to ensure the thread continuity.
[YOCTO #11294]
Signed-off-by: Jose Lamego
---
scripts/create-pull-request | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/scripts/create-pull-request b/scripts/create-pull-request
index e82858b..8f0be99 100755
--- a/scripts/create-pull-request
+++ b/scripts/create-pull-request
@@ -34,7 +34,7 @@ RFC=0
usage() {
CMD=$(basename $0)
cat <"
EOM
}
REMOTE="$CPR_CONTRIB_REMOTE"
# Parse and validate arguments
-while getopts "b:acd:hi:m:o:p:r:s:u:l:" OPT; do
+while getopts "b:acd:hi:m:o:p:r:s:u:l:t:" OPT; do
case $OPT in
b)
BRANCH="$OPTARG"
@@ -108,7 +110,10 @@ while getopts "b:acd:hi:m:o:p:r:s:u:l:" OPT; do
a)
CPR_CONTRIB_AUTO_PUSH="1"
;;
- esac
+t)
+IN_REPLY_TO="$OPTARG"
+;;
+esac
done
if [ -z "$REMOTE" ]; then
@@ -205,7 +210,11 @@ if [ -n "$RELDIR" ]; then
fi
# Generate the patches and cover letter
-git format-patch $extraopts -M40 --subject-prefix="$PREFIX" -n -o $ODIR
--thread=shallow --cover-letter $RELATIVE_TO..$COMMIT_ID > /dev/null
+if [ -n "$IN_REPLY_TO" ]; then
+git format-patch $extraopts -M40 --subject-prefix="$PREFIX" -n -o $ODIR
--thread=shallow --in-reply-to="$IN_REPLY_TO" --cover-letter
$RELATIVE_TO..$COMMIT_ID > /dev/null
+else
+git format-patch $extraopts -M40 --subject-prefix="$PREFIX" -n -o $ODIR
--thread=shallow --cover-letter $RELATIVE_TO..$COMMIT_ID > /dev/null
+fi
if [ -z "$(ls -A $ODIR 2> /dev/null)" ]; then
echo "ERROR: $ODIR is empty, no cover letter and patches was generated!"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] GNU/Octave
FYI here's a guide I have been keeping mostly up-to-date about what you need to do to migrate a recipe from OE-Classic: http://www.openembedded.org/wiki/Migrating_metadata_to_OE-Core Cheers, Paul On Thursday, 6 April 2017 1:48:08 AM NZST Fabio Berton wrote: > You can write a new recipe using > https://github.com/openembedded/openembedded/tree/master/recipes/octave > as a start point, and also see gentoo ebuild to check runtime depends or > get some inspiration :) > https://gitweb.gentoo.org/repo/gentoo.git/tree/sci-mathematics/octave/octave > -4.2.1.ebuild > On 04/05/2017 10:38 AM, Trevor Woerner wrote: > > On Wed, Apr 5, 2017 at 9:22 AM, Fabien Lahoudere > > > > wrote: > >> On Wed, 2017-04-05 at 14:45 +0200, Peter Balazovic wrote: > >>> do you know is there recipe for GNU/Octave > >>> "https://www.gnu.org/software/octave/";? Is it possible to get it > >>> running on Yocto/Linux machine? > > > > In general, when looking for a recipe a good place to start is the layer > > index: https://layers.openembedded.org > > > > After that, google is the next place to try :-) > > > >> A quick google search return this : > >> https://github.com/openembedded/openembedded/tree/master/recipes/octave > > > > That recipe comes for the "openembedded *classic*" repository, which > > was abandoned years ago. So it might work, or it might needs lots of > > tweaking to get it to work, or it might need to be rewritten. -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] QA Test Report for Yocto Project Release 2.3 M3 rc2
Hello All, Here is the report for the Full QA Cycle on Release 2.3 M3 rc2 Full Report : https://wiki.yoctoproject.org/wiki/WW14_-_2017-03-28_-_Full_Test_Cycle_2.3_M 3_rc2 Summary The QA cycle for release 2.3 M3 rc2 is complete. There are 3 new issues found, 2 of them are High and one is M+. Bug 11284 was not allowing Selftest execution so a workaround was provided (read more details within the bug description). Although it does not block M3 rc2, this issue will need to get addressed before the mayor release. In relation to Performance, all of the tasks measurements remained relatively without changes compared to the previous version with small percentage variations between -1.35% to 3.31% on both machines. pTest shows improvements on strace and valgrind, but small regressions on tcl and util-linux. QA Hints - There are 5 high bugs that are still open, so we should keep focus on this for M4. = Details Bugs * New - High o 11267 X can not launch on beaglebone [1] o 11284 selftest: tests that capture output fail on GDC Autobuilders [2] - M+ o 11266 runqemu: fails when rm_work is active [3] * High / M+ Not New o 9 runqemu-extract-sdk is failing when extracting .tar.bz file [4] o 11222 [eclipse] C compiler cannot create executables when reconfiguring project [5] o 10477 yocto-bsp: tool should output a conf file to be consume by the qemu runner [6] o 11193 runqemu can not launch image if enable "rm_work" [7] o 11223 devtool runqemu doesn't work in eSDK [8] Full Bug Report : https://wiki.yoctoproject.org/wiki/WW14_-_2017-03-28_-_Full_Test_Cycle_2.3_M 3_rc2#Bugs_Found_during_QA_Test = == Performance == Performance measurements on both Fedora and Ubuntu machines were relatively stable compared to the previous release, with percentage variations between -1.35% to 3.31%. The Fedora machine showed improvements in all tasks except a small regression on rmwork. Below are the tables with the times of the tests: -Ubuntu Test 2.3 M3 rc12.3 M3 rc2% sato 1:10:15 1:10:00 -0.36 rootfs 2:28 2:26 -1.35 rmwork 1:05:28 1:04:47 -1.04 kernel 5:11 5:12 0.32 eSDK 3:01 3:07 3.31 -Fedora Test 2.3 M3 rc1 2.3 M3 rc2% sato 1:12:341:14:57 3.28 rootfs 2:40 2:44 2.50 rmwork 1:07:101:06:45 -0.62 kernel 6:29 6:38 2.31 eSDK 3:17 3:20 1.52 Performance Charts : https://wiki.yoctoproject.org/charts/perf_milestone_GDC/performance_test.htm l = pTest - There were improvements on pass rates for the strace and valgrind modules - Modules that decreased pass rate were tcl and util-linux - No new bugs were added, although there are 12 issues still open pTest full report : https://wiki.yoctoproject.org/wiki/WW14_-_2017-03-28_-_Full_Test_Cycle_2.3_M 3_rc2#pTest_for_genericx86-64_on_NUC Direct links to the Bugs 1. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11267 2. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11284 3. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11266 4. https://bugzilla.yoctoproject.org/show_bug.cgi?id=9 5. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11222 6. https://bugzilla.yoctoproject.org/show_bug.cgi?id=10477 7. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11193 8. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11223 Regards, Jair Gonzalez -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-qt4][PATCH] sip: remove in favour of meta-oe recipe
Version 4.12 of python-pyqt that we are about to upgrade to requires sip
4.19 which is already in meta-oe, so this version is no longer working.
We shouldn't really be carrying a duplicate recipe here, but on the
other hand we don't want to be adding a hard dependency on meta-oe
either. As a compromise, drop the sip recipe here and require the user
to add meta-oe in order to build it, and a corresponding note to the
README.
Signed-off-by: Paul Eggleton
---
README | 7 +
recipes-qt4/recipes-python/sip_4.16.4.bb | 54
2 files changed, 7 insertions(+), 54 deletions(-)
delete mode 100644 recipes-qt4/recipes-python/sip_4.16.4.bb
diff --git a/README b/README
index 49c3ab2..cebdacd 100644
--- a/README
+++ b/README
@@ -23,6 +23,13 @@ subdirectory: meta
branch: master
revision: HEAD
+If you want to build python-pyqt you will also need meta-oe:
+
+URI: git://github.com/openembedded/meta-openembedded
+subdirectory: meta-oe
+branch: master
+revision: HEAD
+
Maintenance
---
diff --git a/recipes-qt4/recipes-python/sip_4.16.4.bb
b/recipes-qt4/recipes-python/sip_4.16.4.bb
deleted file mode 100644
index 032d125..000
--- a/recipes-qt4/recipes-python/sip_4.16.4.bb
+++ /dev/null
@@ -1,54 +0,0 @@
-SUMMARY = "SIP is a C++/Python Wrapper Generator"
-AUTHOR = "Phil Thompson"
-HOMEPAGE = "http://www.riverbankcomputing.co.uk/sip";
-SECTION = "devel"
-LICENSE = "GPLv2+"
-LIC_FILES_CHKSUM = "file://LICENSE-GPL2;md5=e91355d8a6f8bd8f7c699d62863c7303"
-DEPENDS_class-target = "qt4-x11-free python"
-
-# riverbankcomputing is upstream, but keeps only latest version, sf usually
have few older
-#SRC_URI =
"http://www.riverbankcomputing.com/static/Downloads/sip4/sip-${PV}.tar.gz";
-SRC_URI = "${SOURCEFORGE_MIRROR}/project/pyqt/sip/sip-${PV}/sip-${PV}.tar.gz"
-SRC_URI[md5sum] = "a9840670a064dbf8f63a8f653776fec9"
-SRC_URI[sha256sum] =
"ceda443fc5e129e67a067e2cd7b73ff037f8b10b50e407baa2b1d9f2199d57f5"
-
-BBCLASSEXTEND = "native"
-
-PACKAGES += "python-sip"
-
-inherit qmake2 python-dir pythonnative distro_features_check
-# depends on qt4-x11-free
-REQUIRED_DISTRO_FEATURES = "x11"
-
-EXTRA_QMAKEVARS_POST += "CONFIG=console"
-
-export BUILD_SYS
-export HOST_SYS
-export STAGING_LIBDIR
-export STAGING_INCDIR
-
-do_configure_prepend_class-target() {
-echo "py_platform = linux" > sip.cfg
-echo "py_inc_dir = %(sysroot)/${includedir}/python%(py_major).%(py_minor)"
>> sip.cfg
-echo "sip_bin_dir = ${D}/${bindir}" >> sip.cfg
-echo "sip_inc_dir = ${D}/${includedir}" >> sip.cfg
-echo "sip_module_dir =
${D}/${libdir}/python%(py_major).%(py_minor)/site-packages" >> sip.cfg
-echo "sip_sip_dir = ${D}/${datadir}/sip" >> sip.cfg
-python configure.py --use-qmake --configuration sip.cfg --sysroot
${STAGING_DIR_HOST}
-}
-do_configure_prepend_class-native() {
-echo "py_platform = linux" > sip.cfg
-echo "py_inc_dir = ${includedir}/python%(py_major).%(py_minor)" >> sip.cfg
-echo "sip_bin_dir = ${D}/${bindir}" >> sip.cfg
-echo "sip_inc_dir = ${D}/${includedir}" >> sip.cfg
-echo "sip_module_dir =
${D}/${libdir}/python%(py_major).%(py_minor)/site-packages" >> sip.cfg
-echo "sip_sip_dir = ${D}/${datadir}/sip" >> sip.cfg
-python configure.py --use-qmake --configuration sip.cfg --sysroot
${STAGING_DIR_NATIVE}
-}
-do_install() {
-oe_runmake install
-}
-
-FILES_python-${BPN} = "${libdir}/${PYTHON_DIR}/site-packages/"
-FILES_${PN}-dbg += "${libdir}/${PYTHON_DIR}/site-packages/.debug"
-
--
2.9.3
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Local repo no network help request
Hi all,
I am trying to do the following:
I have a local git repo, pulled manually from a remote repo (via a script).
I have a .bb file set up referencing this repo. This .bb file includes
(among other things):
>> SRC_URI = "git://${TOPDIR}/../sources/my-repo;protocol=file;branch=master"
>> SRCREV = "${AUTOREV}"
I do not want to use the network (so BB_NO_NETWORK is 1).
Although the SRC_URI is pointing to the correct path, the yocto build
fails because it tries to access the network.
How should I be doing this instead?
I can run a script (preferably bash atm) before the build if doing
something pre-build will help simplify anything.
Thank you,
M
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Install rootfs.tar.bz2 to ${D}/home/root/
Hi,
I want to create a deployable SD card image. My board (beaglebone based) boots
from SD card and runs a script which copies the rootfs.tar.bz2 to the flash
memory.
So how can I deploy a copy of the whole rootfs to ${D}/home/root?
A rootfs in the rootfs, does that make sense?
Any help is appreciated.
Chris
i.A. Chris Maier
Software-Entwicklungsingenieur
Phone: +49 7152 203 6741 | Fax: +49 7152 203 76741 | c.ma...@geze.com
GEZE GmbH, Reinhold-Vöster-Straße 21-29, 71229 Leonberg | www.geze.com
SAVE PAPER - THINK BEFORE YOU PRINT
Geschäftsführung: Brigitte Vöster-Alber (Vorsitzende), Andrea
Alexandra Alber, Marc Alber, Florian Birkenmayer
Vorsitzender des Aufsichtsrates: Prof. Dr. Dr. Ulli Arnold, Amtsgericht
Stuttgart HRB 250329, Tel: +49 7152 203 0
GEZE GmbH, Reinhold-Vöster-Straße 21-29, 71229 Leonberg, Germany
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Install rootfs.tar.bz2 to ${D}/home/root/
Hi,
On 06.04.2017 08:41, Maier, Chris wrote:
Hi,
I want to create a deployable SD card image. My board (beaglebone based)
boots from SD card and runs a script which copies the rootfs.tar.bz2 to
the flash memory.
So how can I deploy a copy of the whole rootfs to ${D}/home/root?
A rootfs in the rootfs, does that make sense?
Partially. Sounds like you want to invent your own update mechanism.
Have you had a look at the already existing ones, specifically swupdate?
Greetz
--
Josef Holzmayr
Software Developer Embedded Systems
Tel: +49 8444 9204-48
Fax: +49 8444 9204-50
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548
_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
