[yocto] Changing device tree inside of the devshell
Hi, I had to made some device tree changes inside of a devshell. Just changed the .dts file and exited the shell. I built the image after that and got the message: ...do_compile is tainted from a forced run ...do_deploy is tainted from a forced run which made sense given the manual changes I've done. However, the changes haven't made their way into the image. Even when explicitly doing a deploy step (linux-senic is our kernel recipe): bitbake linux-senic -C deploy the correct .dtb doesn't find it's way into the image final image. My assumption was that any changes done in the devshell would be recognized and the required steps will be rerun automatically on a full image build. This ended false. Anyone knows where the error might lay? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Run application at system boot
Hello yocto community, I want to know a few things about how to configure yocto such that - a simple application (let's say a hello world C program from a new recipe) is run at boot time. - run a kernel module from a simple recipe at boot time and automatically build its "/dev/hello" interface file (which normally is done by hand using mknod). I appreciate any hint, example or tutorial regarding this questions. Thank you very much, Laurentiu -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Run application at system boot
Hi, On Tue, Dec 5, 2017 at 3:21 PM, Laurentiu-Cristian Duca wrote: > Hello yocto community, > > I want to know a few things > about how to configure yocto such that > - a simple application (let's say a hello world C program > from a new recipe) is run at boot time. depends which init system you're using. By default in yocto there is sysVInit and basically you need to write simple script which will be used by sysVInit to start/stop your program Look here: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes-update-rc.d > - run a kernel module from a simple recipe at boot time > and automatically build its "/dev/hello" interface file > (which normally is done by hand using mknod). Look here: http://www.yoctoproject.org/docs/2.4/ref-manual/ref-manual.html#migration-1.7-kernel-module-autoloading > > I appreciate any hint, example or tutorial regarding this questions. > > Thank you very much, > Laurentiu > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Project Technical Team Meeting
Attendees: Stephen, Saul, Stephano, Aaron, Richard, Armin, Rob, Brian, Chin Huat, Patrick, Randy, Mark, Ross, Christian, Joshua W., wmills, Michael, Agenda: * Yocto Project status - 5 min (Stephen/team) * YP 2.5 M1 is getting ready to build, but the build/test environment is not stable. This has slowed the patch merging and so we haven't built it yet. * YP 2.2.3 and YP 2.3.3 are also seeing build/test issues and have not been sent to QA yet. If we root cause the issues we might get the milestone and/or dot releases into QA. * YP 2.4.1 should go into QA shortly if we get a successful build, we has good builds recently. * Opens - 10 min * Richard - Discussed issues with build environment and issues we are seeing. See weekly status for details on these issues. * Team Sharing - 10 min * Saul - Discussed that we should move the kernel from 4.12 to 4.14 in YP 2.5. Bruce will drive this update. * Armin - YP 2.4.1 (Rocko) is ready to build. YP 2.3.3 (Pyro) is not yet ready build failures. YP 2.2.3 (Morty) is also not ready yet due to a smart issue. * Richard - Discussed that YP Compatibility v2 is not ready to go into YP 2.5 yet, due to the fact that Richard has focused the last few weeks on getting the build/test environment stable. Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 * Work Telephone: (503) 712-0534 *Cell: (208) 244-4460 * Email:stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Removing /usr/src/debug from image
Hi, I have edited my local.conf to remove the debug related EXTRA_IMAGE_FEATURES. My rootfs still contains a /usr/src/debug folder, which I would like to get rid of. This likely come from -dbg package inclusion, which I would like to understand how to control/remove. We are using Yocto 1.9/2.0, and the only thing I found related to this is INHIBIT_PACKAGE_DEBUG_SPLIT = "1" Yet, from documentation this appears to be about generating the -dbg packages which I do not mind, but I do not want them install in my image. I am trying to understand what pulls them in. My image recipe pulls the packagegroup-core-boot, ROOTFS_PKGMANAGE_BOOTSTRAP, CORE_IMAGE_EXTRA_INSTALL, ca-certificates, package-management and some other private package but none of those include -dbg... Any help appreciated. -- Yannick Koehler -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Removing /usr/src/debug from image
On 12/5/17 12:40 PM, Koehler, Yannick wrote: > Hi, > > I have edited my local.conf to remove the debug related EXTRA_IMAGE_FEATURES. > My rootfs still contains a /usr/src/debug folder, which I would like to get > rid of. This likely come from -dbg package inclusion, which I would like to > understand how to control/remove. We are using Yocto 1.9/2.0, and the only > thing I found related to this is > > INHIBIT_PACKAGE_DEBUG_SPLIT = "1" The above is definitely not what you want. It will keep debug symbols in all of your binaries, increasing the size of the eventual image. The base-files recipe created a set of directories. If this directory is empty on your resulting image, I would assume it is created from there. If this is a concern, create a bbappend and remove that directory in a do_install_append. Is there any particular reason you want it removed? It should only be taking 1 inode, assuming it is empty. > Yet, from documentation this appears to be about generating the -dbg packages > which I do not mind, but I do not want them install in my image. I am trying > to understand what pulls them in. My image recipe pulls the > packagegroup-core-boot, ROOTFS_PKGMANAGE_BOOTSTRAP, CORE_IMAGE_EXTRA_INSTALL, > ca-certificates, package-management and some other private package but none > of those include -dbg... > > Any help appreciated. > > -- > Yannick Koehler > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] externalsrc + sstate why is not compatible?
In our situation, we have many packages that are in-house, as such we use a local folder for the several in-house modules. To do so, we need to use externalsrc to point to the local code so that the git repo contains both the code + recipe, instead of 20 repos (1 per packages) and 1 more for yocto recipe which complicates things when you want to submit a change. Yet, the externalsrc disable the setscene tasks and set the BB_DONTCACHE variable. I altered the script to remove those but then a change to the externalsrc folder is not detected. I wonder if it is because the S variable is set past the sstate algorithm and is then unable to consider the externalsrc folder as the real source location. Any expert on this matter that can guide me to either make sstate works for external src or teach me how to have code + recipe in a single git repo. I am certainly not the only case using such a pattern. -- Yannick Koehler -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] bitbake menuconfig fails
Hello We are using in our layer a kernel 4.8 recipe (linux-stable_4.8.bb)- everything ok. I'm trying to upgrade to 4.14, I created a new recipe linux-stable_4.14.bb. They live side by side, for now. But with the 4.14 kernel when running `bitbake -c menuconfig linux-stable`, the new terminal comes up and I get the following error: HOSTCC scripts/basic/fixdep GEN ./Makefile HOSTCC scripts/kconfig/mconf.o HOSTCC scripts/kconfig/zconf.tab.o HOSTCC scripts/kconfig/lxdialog/checklist.o HOSTCC scripts/kconfig/lxdialog/util.o HOSTCC scripts/kconfig/lxdialog/inputbox.o HOSTCC scripts/kconfig/lxdialog/textbox.o HOSTCC scripts/kconfig/lxdialog/yesno.o HOSTCC scripts/kconfig/lxdialog/menubox.o HOSTLD scripts/kconfig/mconf /usr/bin/ld: cannot find -lncursesw collect2: error: ld returned 1 exit status scripts/Makefile.host:111: recipe for target 'scripts/kconfig/mconf' failed make[3]: *** [scripts/kconfig/mconf] Error 1 /media/mircea/ExtLinux/Adventure/testBuildServer/product-sama5-kernel/yocto/build/tmp/work-shared/cuxe/kernel-source/Makefile:548: recipe for target 'menuconfig' failed make[2]: *** [menuconfig] Error 2 Makefile:146: recipe for target 'sub-make' failed make[1]: *** [sub-make] Error 2 Makefile:24: recipe for target '__sub-make' failed make: *** [__sub-make] Error 2 Command failed. If I rename linux-stable_4.14.bb to linux-stable_4.14.bb___, then run bitbake again (now the build system is working with the 4.8 kernel again) => menuconfig starts and works as expected. I'm using krogoth, 2.1.2, Debian 8 (jessie) I also tried to config the kernel outside of yocto, downloaded https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.14.4.tar.xz, extracted and run make menuconfig => works as expected Any hints are appreciated. Thanks -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake menuconfig fails
Hello Mircea, >From my point of view: *> /usr/bin/ld: cannot find -lncursesw* > collect2: error: ld returned 1 exit status > scripts/Makefile.host:111: recipe for target 'scripts/kconfig/mconf' failed The first line explains it all. You could not configure 4.14, since for this you should have ncurses package. I would further say, the YOCTO ncurses version you have, which is used for 4.8 is outdated, so you need newer (matching) YOCTO version for 4.14. Why you are able to configure 4.14 outside of yocto? Because you use another version of ncurses, one which is host native to Debian 8. YOCTO probably uses some other host based ncurses inside YOCTO (in Open Embedded/meta layer, my best guess). Zoran On Wed, Dec 6, 2017 at 7:31 AM, Mircea Gliga wrote: > Hello > > We are using in our layer a kernel 4.8 recipe (linux-stable_4.8.bb)- > everything ok. > I'm trying to upgrade to 4.14, I created a new recipe linux-stable_4.14.bb. > They live side by side, for now. > But with the 4.14 kernel when running `bitbake -c menuconfig > linux-stable`, the new terminal comes up and I get the following error: > > HOSTCC scripts/basic/fixdep > GEN ./Makefile > HOSTCC scripts/kconfig/mconf.o > HOSTCC scripts/kconfig/zconf.tab.o > HOSTCC scripts/kconfig/lxdialog/checklist.o > HOSTCC scripts/kconfig/lxdialog/util.o > HOSTCC scripts/kconfig/lxdialog/inputbox.o > HOSTCC scripts/kconfig/lxdialog/textbox.o > HOSTCC scripts/kconfig/lxdialog/yesno.o > HOSTCC scripts/kconfig/lxdialog/menubox.o > HOSTLD scripts/kconfig/mconf > /usr/bin/ld: cannot find -lncursesw > collect2: error: ld returned 1 exit status > scripts/Makefile.host:111: recipe for target 'scripts/kconfig/mconf' failed > make[3]: *** [scripts/kconfig/mconf] Error 1 > /media/mircea/ExtLinux/Adventure/testBuildServer/product- > sama5-kernel/yocto/build/tmp/work-shared/cuxe/kernel-source/Makefile:548: > recipe for target 'menuconfig' failed > make[2]: *** [menuconfig] Error 2 > Makefile:146: recipe for target 'sub-make' failed > make[1]: *** [sub-make] Error 2 > Makefile:24: recipe for target '__sub-make' failed > make: *** [__sub-make] Error 2 > Command failed. > > > If I rename linux-stable_4.14.bb to linux-stable_4.14.bb___, then run > bitbake again (now the build system is working with the 4.8 kernel again) > => menuconfig starts and works as expected. > > I'm using krogoth, 2.1.2, Debian 8 (jessie) > > I also tried to config the kernel outside of yocto, downloaded > https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.14.4.tar.xz, > extracted and run make menuconfig => works as expected > > Any hints are appreciated. > > Thanks > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] samhain: remove the path for start-stop-daemon
From: Mingli Yu
Remove the absolute path for start-stop-daemon
to fix samhain start-up as start-stop-daemon
sometimes located in /usr/sbin, not the expected
/sbin.
Signed-off-by: Mingli Yu
---
recipes-security/samhain/files/samhain-client.init | 12 ++--
recipes-security/samhain/files/samhain-server.init | 10 +-
recipes-security/samhain/files/samhain-standalone.init | 12 ++--
3 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/recipes-security/samhain/files/samhain-client.init
b/recipes-security/samhain/files/samhain-client.init
index 730e1c4..d5fabed 100644
--- a/recipes-security/samhain/files/samhain-client.init
+++ b/recipes-security/samhain/files/samhain-client.init
@@ -70,15 +70,15 @@ case "$1" in
/bin/rm -f ${PIDFILE}
fi
#
- echo -n "Starting ${NAME}"
- /sbin/start-stop-daemon --start --quiet --exec $DAEMON
+echo -n "Starting ${NAME}"
+start-stop-daemon --start --quiet --exec $DAEMON
RETVAL=$?
samhain_done
;;
stop)
- echo -n "Stopping $NAME"
-( /sbin/start-stop-daemon --stop --quiet --exec $DAEMON )
+echo -n "Stopping $NAME"
+start-stop-daemon --stop --quiet --exec $DAEMON
RETVAL=$?
#
@@ -101,8 +101,8 @@ case "$1" in
;;
reload|force-reload)
- echo -n "Reloading $NAME configuration files"
- /sbin/start-stop-daemon --stop --signal 1 --quiet --exec $DAEMON
+echo -n "Reloading $NAME configuration files"
+start-stop-daemon --stop --signal 1 --quiet --exec $DAEMON
RETVAL=$?
samhain_done
;;
diff --git a/recipes-security/samhain/files/samhain-server.init
b/recipes-security/samhain/files/samhain-server.init
index 89bd0aa..c456e51 100644
--- a/recipes-security/samhain/files/samhain-server.init
+++ b/recipes-security/samhain/files/samhain-server.init
@@ -65,14 +65,14 @@ case "$1" in
fi
#
echo -n "Starting ${NAME}"
- /sbin/start-stop-daemon --start --quiet --exec $DAEMON
+ start-stop-daemon --start --quiet --exec $DAEMON
RETVAL=$?
samhain_done
;;
stop)
- echo -n "Stopping $NAME"
-( /sbin/start-stop-daemon --stop --quiet --exec $DAEMON )
+echo -n "Stopping $NAME"
+start-stop-daemon --stop --quiet --exec $DAEMON
RETVAL=$?
#
@@ -95,8 +95,8 @@ case "$1" in
;;
reload|force-reload)
- echo -n "Reloading $NAME configuration files"
- /sbin/start-stop-daemon --stop --signal 1 --quiet --exec $DAEMON
+echo -n "Reloading $NAME configuration files"
+start-stop-daemon --stop --signal 1 --quiet --exec $DAEMON
RETVAL=$?
samhain_done
;;
diff --git a/recipes-security/samhain/files/samhain-standalone.init
b/recipes-security/samhain/files/samhain-standalone.init
index ac28efd..2f23bff 100644
--- a/recipes-security/samhain/files/samhain-standalone.init
+++ b/recipes-security/samhain/files/samhain-standalone.init
@@ -69,15 +69,15 @@ case "$1" in
/bin/rm -f ${PIDFILE}
fi
- echo -n "Starting ${NAME}"
- ( /sbin/start-stop-daemon --start --quiet --exec $DAEMON )
+echo -n "Starting ${NAME}"
+start-stop-daemon --start --quiet --exec $DAEMON
RETVAL=$?
samhain_done
exit $RETVAL
;;
stop)
-echo -n "Stopping $NAME"
-( /sbin/start-stop-daemon --stop --quiet --exec $DAEMON )
+echo -n "Stopping $NAME"
+start-stop-daemon --stop --quiet --exec $DAEMON
RETVAL=$?
samhain_done
#
@@ -99,8 +99,8 @@ case "$1" in
;;
reload|force-reload)
-echo -n "Reloading $NAME configuration files"
-( /sbin/start-stop-daemon --stop --signal 1 --quiet --exec $DAEMON )
+echo -n "Reloading $NAME configuration files"
+start-stop-daemon --stop --signal 1 --quiet --exec $DAEMON
RETVAL=$?
samhain_done
;;
--
2.13.3
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
