Re: [OE-core] adduser: add -k [was: Re: Post USERADD_PARAM action]
On Mon, May 25, 2015 at 10:32 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Fri, May 22, 2015 at 12:37:13PM +0100, Laszlo Papp wrote: Hi, is it possible to do some post action after useradd_param is executed? I would like to modify the created user's home directory, in this special case the profile. I see that the useradd util has this on desktop, but busybox does not have it, and very likely will not have it, at least not in the near future anyway: mhm, why so? People tend to complain about not very common and minimalistic features going in. Perhaps, if it is optional, it may sneak in easier. Man proposes, Denys disposes. The attached compiles for me. cheers, -k, --skel SKEL_DIR The skeleton directory, which contains files and directories to be copied in the user's home directory, when the home directory is created by useradd. This option is only valid if the -m (or --create-home) option is specified. If this option is not set, the skeleton directory is defined by the SKEL variable in /etc/default/useradd or, by default, /etc/skel. If possible, the ACLs and extended attributes are copied. I would like to do something like this with the created user's home directory: echo PATH=/sbin:$PATH /home/foo/.profile chmod foo:foo /home/foo/.profile But then again, for this, I need to make sure that the user is already created. Ys, L. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Post USERADD_PARAM action
Hi, is it possible to do some post action after useradd_param is executed? I would like to modify the created user's home directory, in this special case the profile. I see that the useradd util has this on desktop, but busybox does not have it, and very likely will not have it, at least not in the near future anyway: -k, --skel SKEL_DIR The skeleton directory, which contains files and directories to be copied in the user's home directory, when the home directory is created by useradd. This option is only valid if the -m (or --create-home) option is specified. If this option is not set, the skeleton directory is defined by the SKEL variable in /etc/default/useradd or, by default, /etc/skel. If possible, the ACLs and extended attributes are copied. I would like to do something like this with the created user's home directory: echo PATH=/sbin:$PATH /home/foo/.profile chmod foo:foo /home/foo/.profile But then again, for this, I need to make sure that the user is already created. Ys, L. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] busybox: passwd: applet not found
Hi, I am a bit confused why busybox passwd does not work with daisy. It used to work with dylan. When I try to use busybox passwd, I am getting the following output: passwd: applet not found Is something wrong with the busybox maintainer script or somewhere else? For instance, busybox pwd can be located as well as some other applets that I have quickly run. Apparently, this does not seem to be in the migration guide either, so I presume that I am doing something wrong, but what exactly? Fwiw, busybox passwd works just fine on my desktop, too, as expected. As for completeness, passwd does work (without the busybox prefix), but that is not what I am aiming for. I am always trying to be explicit because I always want to use busybox's applet, no matter what. So what can I do to overcome this? Ys, L. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On Wed, May 20, 2015 at 4:48 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On May 20, 2015 5:36:55 PM GMT+02:00, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:25 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 17:20, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:17 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 17:09, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:07 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 16:02, Laszlo Papp lp...@kde.org wrote: On a second thought: is even worse now than that, our code has to handle _three_ different scenarios: 1) Desktop. 2) Embedded without Yocto or embedded with old Yocto. 3) Embedded with new Yocto. I do not get excited about this. Do as the documentation says in your distro and you have one scenario. That means compromising security. I am now looking for the ideal case in the future. What is wrong about dropping the privileges in busybox for undedicated processes without creating this separation? That would combine the convenience with security, wouldn't it? We already do that. Since June 2002. version 0.60.4 Then I cannot understand the incompatible change. If the privilege is dropped early and the code is well-understood, then what exactly was being solved in here for the price of incompatibility and more complex environments across projects? But in any case, if BUSYBOX_SPLIT_SUID=0 helps me with being compatible while it still drops the privileges properly as intended by busybox upstream, I guess I can go for that. I am yet to understand the certain users do not follow it part. What exactly? Certain users don't want to risk bugs in the code before privs are dropped. The only way to make them happy is to split the binary into two, a suid one a a nosuid one. OK, well, in that case, the question is: why is it not led by busybox upstream? Currently, busybox downstream projects can call this anything. At least, some standard way would be nice, wouldn't it? The logic where to split is upstream to attempt to have a stable, maintained interface at least. I do not want 2 binaries myself. If there is an attack-vector in the part before dropping privileges then I want to have it fixed. You can ask Denys if he wants to do the 2 binary nonsense upstream, but I will not commit such a thing, fwiw. Well, I understand and appreciate that opinions vary, but if busybox had shipped 3 binaries at the end of the build processes, then their naming would be standard led by busybox upstream. Currently, there is no way to standardize it if Yocto thinks it should be called busybox.suid and e.g. (imaginary example) buildroot thinks it should be called suid.busybox. This would be less than ideal if my software has to work with both. Yes, Denys would need to be convinced for this, but for the time being, I do not have enough time to get it through. Anyway, thank you for your replies. I deem them helpful and prompt. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On Wed, May 20, 2015 at 4:25 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 17:20, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:17 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 17:09, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:07 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 16:02, Laszlo Papp lp...@kde.org wrote: On a second thought: is even worse now than that, our code has to handle _three_ different scenarios: 1) Desktop. 2) Embedded without Yocto or embedded with old Yocto. 3) Embedded with new Yocto. I do not get excited about this. Do as the documentation says in your distro and you have one scenario. That means compromising security. I am now looking for the ideal case in the future. What is wrong about dropping the privileges in busybox for undedicated processes without creating this separation? That would combine the convenience with security, wouldn't it? We already do that. Since June 2002. version 0.60.4 Then I cannot understand the incompatible change. If the privilege is dropped early and the code is well-understood, then what exactly was being solved in here for the price of incompatibility and more complex environments across projects? But in any case, if BUSYBOX_SPLIT_SUID=0 helps me with being compatible while it still drops the privileges properly as intended by busybox upstream, I guess I can go for that. I am yet to understand the certain users do not follow it part. What exactly? Certain users don't want to risk bugs in the code before privs are dropped. The only way to make them happy is to split the binary into two, a suid one a a nosuid one. OK, well, in that case, the question is: why is it not led by busybox upstream? Currently, busybox downstream projects can call this anything. At least, some standard way would be nice, wouldn't it? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On Wed, May 20, 2015 at 4:07 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 16:02, Laszlo Papp lp...@kde.org wrote: On a second thought: is even worse now than that, our code has to handle _three_ different scenarios: 1) Desktop. 2) Embedded without Yocto or embedded with old Yocto. 3) Embedded with new Yocto. I do not get excited about this. Do as the documentation says in your distro and you have one scenario. That means compromising security. I am now looking for the ideal case in the future. What is wrong about dropping the privileges in busybox for undedicated processes without creating this separation? That would combine the convenience with security, wouldn't it? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On Wed, May 20, 2015 at 4:17 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 17:09, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:07 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 16:02, Laszlo Papp lp...@kde.org wrote: On a second thought: is even worse now than that, our code has to handle _three_ different scenarios: 1) Desktop. 2) Embedded without Yocto or embedded with old Yocto. 3) Embedded with new Yocto. I do not get excited about this. Do as the documentation says in your distro and you have one scenario. That means compromising security. I am now looking for the ideal case in the future. What is wrong about dropping the privileges in busybox for undedicated processes without creating this separation? That would combine the convenience with security, wouldn't it? We already do that. Since June 2002. version 0.60.4 Then I cannot understand the incompatible change. If the privilege is dropped early and the code is well-understood, then what exactly was being solved in here for the price of incompatibility and more complex environments across projects? But in any case, if BUSYBOX_SPLIT_SUID=0 helps me with being compatible while it still drops the privileges properly as intended by busybox upstream, I guess I can go for that. I am yet to understand the certain users do not follow it part. What exactly? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On Wed, May 20, 2015 at 3:45 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 15:42, Laszlo Papp lp...@kde.org wrote: Now that just breaks all the code that our software is using. Why did this binary incompatible change sneak in, and especially: why without any note in the migration guide? Furthermore, is there a way to reverse this? I really would like to avoid rewriting my code just because some other people think it is a cool change. Or is this change absolutely necessary? The point was to not give normal applets such as cat suid rights. Why can't your scripts just call passwd directly instead of proxying through busybox? If busybox is available on desktop, I would like to call the busybox applet through 'busybox appletname'. If I just call passwd, I will call the desktop version. That is not what I want and this is not how it has so far worked. I think this feature should have been at least optional and if it has to break, it is definitely something to document in the migration guide, isn't it? Currently, I do not see any simple way without #ifdef jungle in the code around to it. It is not nice. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On Wed, May 20, 2015 at 3:58 PM, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 3:54 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 15:50, Laszlo Papp lp...@kde.org wrote: Currently, I do not see any simple way without #ifdef jungle in the code around to it. It is not nice. Looking at the busybox recipe reveals this: # Whether to split the suid apps into a seperate binary BUSYBOX_SPLIT_SUID ?= 1 Just remember that the suid apps were being split out for good security reasons. There's no need for sed to have suid rights! I will not argue about security measure improvements as I agree about them with you. However, I will debate the way this security measure is implemented. It is distraction from the desktop world where you can also use busybox and many use. Now, all of a sudden, we have to handle them differently in code and scripts. I think a less intrusive approach to implement this could have been (and probably still not late) is to fix the rights underneath and not by such wrappers. Such wrappers will introduce this disruption which is not strictly needed. Well, you could say that if desktop distributions also implement it like this, then there is no disruption, but I think that is never going to happen if busybox itself does not enforce it. I think this is not a good implementation for security to remain consistent with the rest of the world. Could it be please reconsidered towards another solutions? It is also good if one call tell me how to solve this differentiation between desktop and Yocto without further code. On a second thought: is even worse now than that, our code has to handle _three_ different scenarios: 1) Desktop. 2) Embedded without Yocto or embedded with old Yocto. 3) Embedded with new Yocto. I do not get excited about this. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On Wed, May 20, 2015 at 3:05 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 15:48, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 13:55, Laszlo Papp lp...@kde.org wrote: Hi, I am a bit confused why busybox passwd does not work with daisy. It used to work with dylan. When I try to use busybox passwd, I am getting the following output: passwd: applet not found is the password applet built? Check your busybox .config. Is passwd listed when you invoke plain busybox and have the help-text printing turned on? Sometimes code around bsearch is miscompiled but this should not be the case for your setup, i suppose. ah, the great suid / nosuid split ? try /bin/busybox.suid passwd instead, the default /bin/busybox supposedly points to the .nosuid binary. Now that just breaks all the code that our software is using. Why did this binary incompatible change sneak in, and especially: why without any note in the migration guide? Furthermore, is there a way to reverse this? I really would like to avoid rewriting my code just because some other people think it is a cool change. Or is this change absolutely necessary? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On Wed, May 20, 2015 at 3:54 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 15:50, Laszlo Papp lp...@kde.org wrote: Currently, I do not see any simple way without #ifdef jungle in the code around to it. It is not nice. Looking at the busybox recipe reveals this: # Whether to split the suid apps into a seperate binary BUSYBOX_SPLIT_SUID ?= 1 Just remember that the suid apps were being split out for good security reasons. There's no need for sed to have suid rights! I will not argue about security measure improvements as I agree about them with you. However, I will debate the way this security measure is implemented. It is distraction from the desktop world where you can also use busybox and many use. Now, all of a sudden, we have to handle them differently in code and scripts. I think a less intrusive approach to implement this could have been (and probably still not late) is to fix the rights underneath and not by such wrappers. Such wrappers will introduce this disruption which is not strictly needed. Well, you could say that if desktop distributions also implement it like this, then there is no disruption, but I think that is never going to happen if busybox itself does not enforce it. I think this is not a good implementation for security to remain consistent with the rest of the world. Could it be please reconsidered towards another solutions? It is also good if one call tell me how to solve this differentiation between desktop and Yocto without further code. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Migration from dylan to daisy (and dizzy)
Dear OpenEmbedded Community, I have been trying to migrate over from dylan to daisy (and dizzy, fwiw), but my own kernel would not boot. It used to work just fine with dylen. It is kernel 3.2 with our BSP changes on top of it, which are unfortunately not upstream. Either way, dylan was using 4.7 and I tried to build the kernel with gcc 4.8 from daisy and gcc 4.9 from dizzy. I suspect that it is a toolchain and/or kernel issue, definitely not Yocto as I can reproduce this with some Linaro binaries for arm gnueabi. Still, I hope that some may have some ideas while working in scenarios like this? Jtag with openocd and gdb shows the following backtrace, where foo_map_io comes from our board description. As you can see it is fundamentally broken as it gets stuck at the early register access, even before printk could be used! I tried using early_prink by enabling debug_ll, but it did not work out for me. Like I wrote, this is a really early stage of the booting process. Has anyone experienced similar issues? I would like to update our Yocto, but it is becoming very difficult as I do not possess the corresponding gcc and linux expertise, unfortunately. :( Thank you in advance! (gdb) bt #0 0xc0016f40 in davinci_psc_config () #1 0xc00164b8 in __clk_enable () #2 0xc00165cc in clk_enable () #3 0xc03aa8b0 in davinci_clk_init () #4 0xc03ab2ec in davinci_common_init () #5 0xc03ab52c in da850_init () #6 0xc03ac360 in foo_map_io () #7 0xc03aa2d4 in paging_init () #8 0xc03a8640 in setup_arch () #9 0xc03a6590 in start_kernel () #10 0xc0008040 in stext () (gdb) Ys, L. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add init script (sysv) support for busybox's ntpd
On Sun, Mar 1, 2015 at 9:34 PM, Alexandre Belloni alexandre.bell...@free-electrons.com wrote: On 01/03/2015 at 13:48:11 +, Laszlo Papp wrote : I finally decided to get this patch another go, even though still no busybox daemon has LSB headers, but I would need to ask for some prime example of LSB headers that I can start off with. Could anyone please provide me a good example for that from the Yocto project? Thanks. What about: ### BEGIN INIT INFO # Provides: ntpd # Required-Start:$network # Required-Stop: $network # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: NTP daemon # Description: Network Time Protocol (NTP) is a networking #protocol for clock synchronization ### END INIT INFO See http://www.linuxbase.org/betaspecs/lsb/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html I forgot to mention that Martin Jansa gave me a good example yesterday. But thanks anyway. It is helpful. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Add init script (sysv) support for busybox's ntpd
Signed-off-by: Laszlo Papp laszlo.p...@polatis.com
---
meta/recipes-core/busybox/busybox.inc | 12 +++--
meta/recipes-core/busybox/busybox_1.23.1.bb | 2 +
meta/recipes-core/busybox/files/busybox-ntpd | 54 +++
meta/recipes-core/busybox/files/busybox-ntpd.conf | 2 +
4 files changed, 67 insertions(+), 3 deletions(-)
create mode 100644 meta/recipes-core/busybox/files/busybox-ntpd
create mode 100644 meta/recipes-core/busybox/files/busybox-ntpd.conf
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index 0769d92..b33d624 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -19,7 +19,7 @@ export EXTRA_CFLAGS = ${CFLAGS}
export EXTRA_LDFLAGS = ${LDFLAGS}
export EXTRA_OEMAKE += 'LD=${CCLD}'
-PACKAGES =+ ${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev
${PN}-hwclock
+PACKAGES =+ ${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev
${PN}-hwclock ${PN}-ntpd
FILES_${PN}-httpd = ${sysconfdir}/init.d/busybox-httpd /srv/www
FILES_${PN}-syslog = ${sysconfdir}/init.d/syslog*
${sysconfdir}/syslog-startup.conf* ${sysconfdir}/syslog.conf*
${systemd_unitdir}/system/syslog.service ${sysconfdir}/default/busybox-syslog
@@ -27,15 +27,17 @@ FILES_${PN}-mdev = ${sysconfdir}/init.d/mdev
${sysconfdir}/mdev.conf ${sysconfd
FILES_${PN}-udhcpd = ${sysconfdir}/init.d/busybox-udhcpd
FILES_${PN}-udhcpc = ${sysconfdir}/udhcpc.d ${datadir}/udhcpc
FILES_${PN}-hwclock = ${sysconfdir}/init.d/hwclock.sh
+FILES_${PN}-ntpd = ${sysconfdir}/init.d/busybox-ntpd
${sysconfdir}/busybox-ntpd.conf
-INITSCRIPT_PACKAGES = ${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev
${PN}-hwclock
+INITSCRIPT_PACKAGES = ${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev
${PN}-hwclock ${PN}-ntpd
INITSCRIPT_NAME_${PN}-httpd = busybox-httpd
INITSCRIPT_NAME_${PN}-hwclock = hwclock.sh
INITSCRIPT_NAME_${PN}-mdev = mdev
INITSCRIPT_PARAMS_${PN}-mdev = start 03 S .
INITSCRIPT_NAME_${PN}-syslog = syslog
-INITSCRIPT_NAME_${PN}-udhcpd = busybox-udhcpd
+INITSCRIPT_NAME_${PN}-udhcpd = busybox-udhcpd
+INITSCRIPT_NAME_${PN}-ntpd = busybox-ntpd
SYSTEMD_PACKAGES = ${PN}-syslog
SYSTEMD_SERVICE_${PN}-syslog = busybox-syslog.service
@@ -273,6 +275,10 @@ do_install () {
install -m 0755 ${WORKDIR}/mdev-mount.sh
${D}${sysconfdir}/mdev
fi
fi
+if grep CONFIG_NTPD=y ${B}/.config; then
+install -m 0755 ${WORKDIR}/busybox-ntpd ${D}${sysconfdir}/init.d/
+install -m 0644 ${WORKDIR}/busybox-ntpd.conf ${D}${sysconfdir}/
+fi
if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};
then
if grep -q CONFIG_SYSLOGD=y ${B}/.config; then
diff --git a/meta/recipes-core/busybox/busybox_1.23.1.bb
b/meta/recipes-core/busybox/busybox_1.23.1.bb
index 1742390..8e57381 100644
--- a/meta/recipes-core/busybox/busybox_1.23.1.bb
+++ b/meta/recipes-core/busybox/busybox_1.23.1.bb
@@ -31,6 +31,8 @@ SRC_URI =
http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://recognize_connmand.patch \
file://busybox-cross-menuconfig.patch \
file://CVE-2014-9645_busybox_reject_module_names_with_slashes.patch
\
+ file://busybox-ntpd \
+ file://busybox-ntpd.conf \
SRC_URI[tarball.md5sum] = 5c94d6301a964cd91619bd4d74605245
diff --git a/meta/recipes-core/busybox/files/busybox-ntpd
b/meta/recipes-core/busybox/files/busybox-ntpd
new file mode 100644
index 000..b318cda
--- /dev/null
+++ b/meta/recipes-core/busybox/files/busybox-ntpd
@@ -0,0 +1,54 @@
+#!/bin/sh
+
+### BEGIN INIT INFO
+# Provides:
+# Required-Start:$local_fs $remote_fs $network $syslog
+# Required-Stop: $local_fs $remote_fs $network $syslog
+# Default-Start: 2 3 4 5
+# Default-Stop: 0 1 6
+# Short-Description: Small busybox ntp server
+# Description: busybox-ntpd is a small and fast busybox ntp applet
+### END INIT INFO
+
+DAEMON=/sbin/ntpd
+NAME=ntpd
+DESC=Busybox NTP Daemon
+source /etc/busybox-ntpd.conf
+ARGS=-p $PEER
+
+test -f $DAEMON || exit 0
+
+set -e
+
+case $1 in
+start)
+if [ -z $PEER ]; then
+echo PEER needs to be specified
+else
+start-stop-daemon -S -b -n $NAME -a $DAEMON -- $ARGS
+echo done.
+fi
+;;
+stop)
+echo -n stopping $DESC: $NAME...
+start-stop-daemon -K -n $NAME
+echo done.
+;;
+restart)
+echo restarting $DESC: $NAME...
+$0 stop
+$0 start
+echo done.
+;;
+reload)
+echo -n reloading $DESC: $NAME...
+killall -HUP $(basename ${DAEMON})
+echo done.
+;;
+*)
+echo Usage: $0 {start|stop|restart|reload}
+exit 1
+;;
+esac
+
+exit 0
diff --git a/meta/recipes-core/busybox/files/busybox-ntpd.conf
b/meta/recipes-core/busybox/files/busybox-ntpd.conf
new
Re: [OE-core] [PATCH] Add init script (sysv) support for busybox's ntpd
On Mon, Mar 2, 2015 at 10:12 AM, Laszlo Papp lp...@kde.org wrote:
Signed-off-by: Laszlo Papp laszlo.p...@polatis.com
---
meta/recipes-core/busybox/busybox.inc | 12 +++--
meta/recipes-core/busybox/busybox_1.23.1.bb | 2 +
meta/recipes-core/busybox/files/busybox-ntpd | 54
+++
meta/recipes-core/busybox/files/busybox-ntpd.conf | 2 +
4 files changed, 67 insertions(+), 3 deletions(-)
create mode 100644 meta/recipes-core/busybox/files/busybox-ntpd
create mode 100644 meta/recipes-core/busybox/files/busybox-ntpd.conf
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index 0769d92..b33d624 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -19,7 +19,7 @@ export EXTRA_CFLAGS = ${CFLAGS}
export EXTRA_LDFLAGS = ${LDFLAGS}
export EXTRA_OEMAKE += 'LD=${CCLD}'
-PACKAGES =+ ${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev
${PN}-hwclock
+PACKAGES =+ ${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev
${PN}-hwclock ${PN}-ntpd
FILES_${PN}-httpd = ${sysconfdir}/init.d/busybox-httpd /srv/www
FILES_${PN}-syslog = ${sysconfdir}/init.d/syslog*
${sysconfdir}/syslog-startup.conf* ${sysconfdir}/syslog.conf*
${systemd_unitdir}/system/syslog.service ${sysconfdir}/default/busybox-syslog
@@ -27,15 +27,17 @@ FILES_${PN}-mdev = ${sysconfdir}/init.d/mdev
${sysconfdir}/mdev.conf ${sysconfd
FILES_${PN}-udhcpd = ${sysconfdir}/init.d/busybox-udhcpd
FILES_${PN}-udhcpc = ${sysconfdir}/udhcpc.d ${datadir}/udhcpc
FILES_${PN}-hwclock = ${sysconfdir}/init.d/hwclock.sh
+FILES_${PN}-ntpd = ${sysconfdir}/init.d/busybox-ntpd
${sysconfdir}/busybox-ntpd.conf
-INITSCRIPT_PACKAGES = ${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev
${PN}-hwclock
+INITSCRIPT_PACKAGES = ${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev
${PN}-hwclock ${PN}-ntpd
INITSCRIPT_NAME_${PN}-httpd = busybox-httpd
INITSCRIPT_NAME_${PN}-hwclock = hwclock.sh
INITSCRIPT_NAME_${PN}-mdev = mdev
INITSCRIPT_PARAMS_${PN}-mdev = start 03 S .
INITSCRIPT_NAME_${PN}-syslog = syslog
-INITSCRIPT_NAME_${PN}-udhcpd = busybox-udhcpd
+INITSCRIPT_NAME_${PN}-udhcpd = busybox-udhcpd
+INITSCRIPT_NAME_${PN}-ntpd = busybox-ntpd
SYSTEMD_PACKAGES = ${PN}-syslog
SYSTEMD_SERVICE_${PN}-syslog = busybox-syslog.service
@@ -273,6 +275,10 @@ do_install () {
install -m 0755 ${WORKDIR}/mdev-mount.sh
${D}${sysconfdir}/mdev
fi
fi
+if grep CONFIG_NTPD=y ${B}/.config; then
+install -m 0755 ${WORKDIR}/busybox-ntpd ${D}${sysconfdir}/init.d/
+install -m 0644 ${WORKDIR}/busybox-ntpd.conf ${D}${sysconfdir}/
+fi
if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};
then
if grep -q CONFIG_SYSLOGD=y ${B}/.config; then
diff --git a/meta/recipes-core/busybox/busybox_1.23.1.bb
b/meta/recipes-core/busybox/busybox_1.23.1.bb
index 1742390..8e57381 100644
--- a/meta/recipes-core/busybox/busybox_1.23.1.bb
+++ b/meta/recipes-core/busybox/busybox_1.23.1.bb
@@ -31,6 +31,8 @@ SRC_URI =
http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://recognize_connmand.patch \
file://busybox-cross-menuconfig.patch \
file://CVE-2014-9645_busybox_reject_module_names_with_slashes.patch \
+ file://busybox-ntpd \
+ file://busybox-ntpd.conf \
SRC_URI[tarball.md5sum] = 5c94d6301a964cd91619bd4d74605245
diff --git a/meta/recipes-core/busybox/files/busybox-ntpd
b/meta/recipes-core/busybox/files/busybox-ntpd
new file mode 100644
index 000..b318cda
--- /dev/null
+++ b/meta/recipes-core/busybox/files/busybox-ntpd
@@ -0,0 +1,54 @@
+#!/bin/sh
+
+### BEGIN INIT INFO
+# Provides:
+# Required-Start:$local_fs $remote_fs $network $syslog
+# Required-Stop: $local_fs $remote_fs $network $syslog
+# Default-Start: 2 3 4 5
+# Default-Stop: 0 1 6
+# Short-Description: Small busybox ntp server
+# Description: busybox-ntpd is a small and fast busybox ntp applet
+### END INIT INFO
+
+DAEMON=/sbin/ntpd
+NAME=ntpd
+DESC=Busybox NTP Daemon
+source /etc/busybox-ntpd.conf
+ARGS=-p $PEER
+
+test -f $DAEMON || exit 0
+
+set -e
+
+case $1 in
+start)
+if [ -z $PEER ]; then
+echo PEER needs to be specified
+else
+start-stop-daemon -S -b -n $NAME -a $DAEMON -- $ARGS
+echo done.
+fi
+;;
+stop)
+echo -n stopping $DESC: $NAME...
+start-stop-daemon -K -n $NAME
+echo done.
+;;
+restart)
+echo restarting $DESC: $NAME...
+$0 stop
+$0 start
+echo done.
+;;
+reload)
+echo -n reloading $DESC: $NAME...
+killall -HUP $(basename ${DAEMON})
+echo done.
+;;
+*)
+echo Usage: $0
Re: [OE-core] [PATCH] Add init script (sysv) support for busybox's ntpd
I finally decided to get this patch another go, even though still no busybox daemon has LSB headers, but I would need to ask for some prime example of LSB headers that I can start off with. Could anyone please provide me a good example for that from the Yocto project? Thanks. On Fri, Jul 25, 2014 at 2:32 PM, Laszlo Papp lp...@kde.org wrote: Any reason why this feature has never got in? It was submitted more than five months ago, and it would have added some feature to the system even if not _everything_ right from the beginning? On Sat, Mar 22, 2014 at 2:03 PM, Laszlo Papp lp...@kde.org wrote: On Fri, Mar 21, 2014 at 2:39 PM, Martin Jansa martin.ja...@gmail.com wrote: On Fri, Mar 21, 2014 at 01:59:15PM +, Laszlo Papp wrote: On Thu, Mar 20, 2014 at 7:59 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 March 2014 19:01, Laszlo Papp lp...@kde.org wrote: This init script is adding support for sysv and no more. This is also indicated in the first line of the commit message. I am sorry, but I will not test it systemd and with other systems You're not being asked to test with systemd. You're being asked to add LSB-standard sysvinit-specific headers to a sysvinit script. In my understanding, people were referring to two issues: 1) not working with systemd and what not compat modes. This is not something I will test any soon. Other people already know it's causing the issues without LSB headers, so if you just add them, you don't need to test it with systemd, other people who care about systemd will do that for you or at least be OK with adding this script, because it will have LSB headers (so it should work fine in systemd world). If someone is really interested in systemd, et al, unlike me at this point, I guess it is not a big deal to get an LSB header from someone to get it integrated into my change? If no one cares about that, then why bother? So, if someone sends this to me I will integrate it, otherwise there is no point since that means no one cares. But then again, this should not still block the change as it can be added incrementally. I am not sure if it is a good idea to block a feature because it does not provide another feature, too. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Specifying 32 bit dependency for 64 bit software
On Thu, Nov 20, 2014 at 6:17 PM, Laszlo Papp lp...@kde.org wrote: On Tue, Nov 4, 2014 at 11:48 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Mon, 2014-11-03 at 17:29 +, Laszlo Papp wrote: we have a tool that we run during our make run, but this tool is hard-coded for 32 bit. It depends on software like ncurses. I could add ncurses-native in an ideal world; no problem. The problem is that my host environment is 64 bit currently and it is not possible to migrate the whole environment to 32 bit. I am happy to explain the details if needed, but I would love you to trust me about that. =) So, is it possible to say more than just DEPENDS = ncurses-native, something like DEPENDS = ncurses-native:x86 or something? How much of a 32 bit system do you have? Do you at least have a 32 bit capable compiler and C libraries? If so, you could use our general class extension mechanism (BBCLASSEXTEND) to allow 32 bit variants of the native recipes, e.g. a native32 form. Alternatively, a more easier approach would be to build a target like buildtools-tarball with SDKMACHINE=i686 and then install that onto the system you're building on. I am just back from my long vacation. I am sorry about not replying earlier. OK, thank you so much; I will give the buildtools-tarball a go. In the end, it was simpler to use this on my Wheezy (Debian) dpkg --add-architecture i386 apt-get update apt-get install install mylib:i386 Cheers, L. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv3] toolchain-script: Add support for ccache builds with the SDK
On Sat, Nov 29, 2014 at 8:12 PM, Burton, Ross ross.bur...@intel.com wrote: On 29 November 2014 at 08:46, Laszlo Papp lp...@kde.org wrote: Including both Richard Purdie and Saul Wold as they were the main criticizers last time in the beginning of September when I submitted the first version of this patch. I've merged this into my staging branch now that the point of the patch is clear. Thanks! Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain
On Mon, Dec 1, 2014 at 4:44 PM, Burton, Ross ross.bur...@intel.com wrote: On 1 December 2014 at 15:21, Paul Eggleton paul.eggle...@linux.intel.com wrote: Make nativesdk-python-core RRECOMMEND python-modules? This sounds like a reasonable option to me. The split as it is at the moment exists mainly for trimming the target; the SDK is perhaps less sensitive to size constraints. Patch sent. Thanks! Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] python: ensure all of Python is installed in nativesdk
On Mon, Dec 1, 2014 at 4:36 PM, Ross Burton ross.bur...@intel.com wrote:
If any part of Python gets installed in a SDK, we need to ensure that all of
Python gets installed to avoid replacing python in the environment with a
minimal package set.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-devtools/python/python_2.7.3.bb |1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/python/python_2.7.3.bb
b/meta/recipes-devtools/python/python_2.7.3.bb
index 50c751e..7f13e22 100644
--- a/meta/recipes-devtools/python/python_2.7.3.bb
+++ b/meta/recipes-devtools/python/python_2.7.3.bb
@@ -161,6 +161,7 @@ require python-${PYTHON_MAJMIN}-manifest.inc
# manual dependency additions
RPROVIDES_${PN}-core = ${PN}
RRECOMMENDS_${PN}-core = ${PN}-readline
+RRECOMMENDS_${PN}-core_append_class-nativesdk = nativesdk-python-modules
RRECOMMENDS_${PN}-crypt = openssl
RRECOMMENDS_${PN}-crypt_class-nativesdk = nativesdk-openssl
--
1.7.10.4
--
Is it worth referring to bug number 6735?
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv3] toolchain-script: Add support for ccache builds with the SDK
Including both Richard Purdie and Saul Wold as they were the main
criticizers last time in the beginning of September when I submitted
the first version of this patch.
On Thu, Nov 27, 2014 at 5:40 PM, Laszlo Papp lp...@kde.org wrote:
It is necessary to have an SDK for developers who build their software with
ccache to speed up the compilation. Without resolving this, unfortunately the
compilation will fail for them.
Signed-off-by: Laszlo Papp lp...@kde.org
---
meta/classes/toolchain-scripts.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index d5b9675..9836db4 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () {
EXTRAPATH=$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i
done
echo 'export
PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH'
$script
+ echo 'export
CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH'
$script
echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' $script
echo 'export PKG_CONFIG_PATH=$SDKTARGETSYSROOT'$libdir'/pkgconfig'
$script
echo 'export
CONFIG_SITE=${SDKPATH}/site-config-'${multimach_target_sys} $script
@@ -37,6 +38,7 @@ toolchain_create_tree_env_script () {
rm -f $script
touch $script
echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' $script
+ echo 'export
CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}' $script
echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}'
$script
echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' $script
echo 'export CONFIG_SITE=${@siteinfo_get_files(d)}' $script
--
2.1.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv2] toolchain-script: Add support for ccache builds with the SDK
From: Laszlo Papp lp...@kde.org
It is necessary to have an SDK for developers who build their software with
ccache to speed up the compilation. Without resolving this, unfortunately the
compilation will fail for them.
Signed-off-by: Laszlo Papp laszlo.p...@kde.org
---
meta/classes/toolchain-scripts.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index d5b9675..9836db4 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () {
EXTRAPATH=$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i
done
echo 'export
PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH'
$script
+ echo 'export
CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH'
$script
echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' $script
echo 'export PKG_CONFIG_PATH=$SDKTARGETSYSROOT'$libdir'/pkgconfig'
$script
echo 'export
CONFIG_SITE=${SDKPATH}/site-config-'${multimach_target_sys} $script
@@ -37,6 +38,7 @@ toolchain_create_tree_env_script () {
rm -f $script
touch $script
echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' $script
+ echo 'export CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}'
$script
echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}'
$script
echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' $script
echo 'export CONFIG_SITE=${@siteinfo_get_files(d)}' $script
--
2.1.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv3] toolchain-script: Add support for ccache builds with the SDK
It is necessary to have an SDK for developers who build their software with
ccache to speed up the compilation. Without resolving this, unfortunately the
compilation will fail for them.
Signed-off-by: Laszlo Papp lp...@kde.org
---
meta/classes/toolchain-scripts.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index d5b9675..9836db4 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () {
EXTRAPATH=$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i
done
echo 'export
PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH'
$script
+ echo 'export
CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH'
$script
echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' $script
echo 'export PKG_CONFIG_PATH=$SDKTARGETSYSROOT'$libdir'/pkgconfig'
$script
echo 'export
CONFIG_SITE=${SDKPATH}/site-config-'${multimach_target_sys} $script
@@ -37,6 +38,7 @@ toolchain_create_tree_env_script () {
rm -f $script
touch $script
echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' $script
+ echo 'export CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}'
$script
echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}'
$script
echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' $script
echo 'export CONFIG_SITE=${@siteinfo_get_files(d)}' $script
--
2.1.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] ptest-runner: return 1 instead of zero if any test fails
Ping. I have not received a reply for about three months now? What is the problem? On Fri, Aug 29, 2014 at 11:54 AM, Laszlo Papp lp...@kde.org wrote: On Mon, Aug 25, 2014 at 7:42 AM, Stoicescu, CorneliuX corneliux.stoice...@intel.com wrote: Hello, From my experience with ptest, there will always be a few tests failing, so we will always get exit code 1. Ptest is not only about meta-core, you need to remember that. My use case is actually quite different: running ptest only on my binaries, and I will trust the rest of the system. For me, it is critical to see if there is any issues in my system. This patch resolves that use case, but even for Yocto, you really oughta aim for fixing your tests, either with known failure or correct means. Should this better return exit code 0 if the individual tests performed correctly(weather they passed or failed) and 1 if there were any errors during the running of the tests? I do not understand this question. This is what the current change tries to do. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Adding cgdb to meta
Heh, I apparently inspired Ben who three days later added cgdb native to meta-oe. Now, I gained enough motivation to retry this contribution thing. Should I submit my cross version? We cannot use the native variant due to our limited embedded system. Martin, can you advise, please? On Tue, Aug 12, 2014 at 4:56 PM, Laszlo Papp lp...@kde.org wrote: On Tue, Aug 12, 2014 at 4:55 PM, Laszlo Papp lp...@kde.org wrote: On Tue, Aug 12, 2014 at 4:51 PM, Laszlo Papp lp...@kde.org wrote: On Tue, Aug 12, 2014 at 4:48 PM, Burton, Ross ross.bur...@intel.com wrote: On 12 August 2014 16:46, Laszlo Papp lp...@kde.org wrote: That layer is too big. It is nearly everything that is rejected from meta; ok there are some dedicated layers, like meta-networking, but it feels like the last resort shelter where everything can just be thrown at. I do not think it is just us who do not wanna pull it into their project. Never mind, it remains to be a feature in our layer, which is closed source, then. It is a pity, but I will move along. People who think its too big are welcome to copy recipes out of it and sync them manually - that's still better than not sharing the recipe. I am unfortunately not interested in participating to something that I have no intent to even test myself before submitting. meta-oe became a monster can which I personally would not like to deal with. That is said with due-respect. If its goal were reconsidered and split into several small layers, then mayhaps... But it is not there, and I am not sure if it was any soon... Unfortunately, this feature remains proprietary at the point of writing this. As long as it works for me, I will not be too much bothered, although I feel sorry for those who will need to reinvent the recipe, modulo stabilization. But that is alright as long as everyone else finds the IMHO cumbersome workflow with gdb OK for debugging. I think pleasant debugging is very important for developers, and cgdb is still a command line based tool, basically a thing wrapper on top of gdb with ncurses. It is not like ddd and other heavy tools. That is why I thought with minor addition, meta could be increase the software development experience; gdb is just way too raw to be effective. But again, no one else might share this opinion, so let us move on. Here is a reminder screenshot for those who do not know it, just in case: http://cgdb.github.io/images/screenshot_debugging.png Alternatively, feel free to advise any sufficient debugging experience with oe-core. I will happily switch to any opportunities that reach this level. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] ptest-runner: return 1 instead of zero if any test fails
On Thu, Nov 27, 2014 at 6:02 PM, Burton, Ross ross.bur...@intel.com wrote: On 27 November 2014 at 17:53, Laszlo Papp lp...@kde.org wrote: Ping. I have not received a reply for about three months now? What is the problem? http://git.openembedded.org/openembedded-core/commit/?id=d6b1c9e7e29aaa8d71ccb485b7a88863a117a8b1 Thanks. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain
What is the situation on this front?
On Sun, Sep 21, 2014 at 5:02 PM, Marek Vasut ma...@denx.de wrote:
On Friday, September 19, 2014 at 09:25:12 AM, Richard Purdie wrote:
[...]
git grep nativesdk-python-modules doesn't show any matches in
git://git.yoctoproject.org/poky master . Do you mean the
nativesdk-packagegroup- python I crafted or do you refer to something
else please ?
Also, shouldn't full python be installed into all the SDK toolchains ? I
am for example unable to compile U-Boot 2014.10rc with the Yocto SDK
toolchain anymore. The SDK is missing python modules and I cannot easily
override the usage of python from the SDK . So I agree with Laszlo here,
the SDK toolchain is somewhat unusable as it is.
I refer to the package I mentioned:
$ ls -la tmp/deploy/ipk/x86_64-nativesdk/nativesdk-python-modules*
-rw-r--r-- 2 richard richard 1512 Sep 18 17:09
tmp/deploy/ipk/x86_64-nativesdk/nativesdk-python-modules_2.7.3-r0.3.24_x86
_64-nativesdk.ipk
See ${PN}-modules defined in python-2.7-manifest.inc.
Oh I see, sorry. Is there any way to look up packages with bitbake or Yocto
please ?
I agreed there is a problem, I disagree somewhat about how it should be
fixed since you're just installing a set of modules which is defined as
those needed to run bitbake and I don't think this is what you actually
want. There is also the question of whether nativesdk-python should even
be in there...
So would this patch (paste below) work please ? If so, I would submit proper.
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index 10d04ed..7245d53 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -30,7 +30,11 @@ B_task-populate-sdk = ${SDK_DIR}
SDKTARGETSYSROOT = ${SDKPATH}/sysroots/${REAL_MULTIMACH_TARGET_SYS}
-TOOLCHAIN_HOST_TASK ?= nativesdk-packagegroup-sdk-host packagegroup-cross-
canadian-${MACHINE}
+TOOLCHAIN_HOST_TASK ?=\
+ nativesdk-packagegroup-sdk-host \
+ packagegroup-cross-canadian-${MACHINE} \
+ nativesdk-python-modules\
+
TOOLCHAIN_HOST_TASK_ATTEMPTONLY ?=
TOOLCHAIN_TARGET_TASK ?= packagegroup-core-standalone-sdk-target
packagegroup-
core-standalone-sdk-target-dbg
TOOLCHAIN_TARGET_TASK_ATTEMPTONLY ?=
diff --git a/meta/recipes-qt/meta/meta-toolchain-qt.inc b/meta/recipes-
qt/meta/meta-toolchain-qt.inc
index 6b162bd..473a123 100644
--- a/meta/recipes-qt/meta/meta-toolchain-qt.inc
+++ b/meta/recipes-qt/meta/meta-toolchain-qt.inc
@@ -1,4 +1,8 @@
-TOOLCHAIN_HOST_TASK = nativesdk-packagegroup-${QTNAME}-toolchain-host
packagegroup-cross-canadian-${MACHINE}
+TOOLCHAIN_HOST_TASK = \
+ nativesdk-packagegroup-${QTNAME}-toolchain-host \
+ packagegroup-cross-canadian-${MACHINE} \
+ nativesdk-python-modules\
+
TOOLCHAIN_TARGET_TASK = packagegroup-${QTNAME}-toolchain-target
TOOLCHAIN_OUTPUTNAME = ${SDK_NAME}-toolchain-${QTNAME}-${DISTRO_VERSION}
Best regards,
Marek Vasut
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Specifying 32 bit dependency for 64 bit software
On Tue, Nov 4, 2014 at 11:48 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Mon, 2014-11-03 at 17:29 +, Laszlo Papp wrote: we have a tool that we run during our make run, but this tool is hard-coded for 32 bit. It depends on software like ncurses. I could add ncurses-native in an ideal world; no problem. The problem is that my host environment is 64 bit currently and it is not possible to migrate the whole environment to 32 bit. I am happy to explain the details if needed, but I would love you to trust me about that. =) So, is it possible to say more than just DEPENDS = ncurses-native, something like DEPENDS = ncurses-native:x86 or something? How much of a 32 bit system do you have? Do you at least have a 32 bit capable compiler and C libraries? If so, you could use our general class extension mechanism (BBCLASSEXTEND) to allow 32 bit variants of the native recipes, e.g. a native32 form. Alternatively, a more easier approach would be to build a target like buildtools-tarball with SDKMACHINE=i686 and then install that onto the system you're building on. I am just back from my long vacation. I am sorry about not replying earlier. OK, thank you so much; I will give the buildtools-tarball a go. Cheers, L. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Specifying 32 bit dependency for 64 bit software
Hi, we have a tool that we run during our make run, but this tool is hard-coded for 32 bit. It depends on software like ncurses. I could add ncurses-native in an ideal world; no problem. The problem is that my host environment is 64 bit currently and it is not possible to migrate the whole environment to 32 bit. I am happy to explain the details if needed, but I would love you to trust me about that. =) So, is it possible to say more than just DEPENDS = ncurses-native, something like DEPENDS = ncurses-native:x86 or something? Cheers, L. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Specifying 32 bit dependency for 64 bit software
Forgot to mention, but any nice workarounds are appreciated. I have a few ideas, but they are all a bit ugly and non-robust. On Mon, Nov 3, 2014 at 5:29 PM, Laszlo Papp lp...@kde.org wrote: Hi, we have a tool that we run during our make run, but this tool is hard-coded for 32 bit. It depends on software like ncurses. I could add ncurses-native in an ideal world; no problem. The problem is that my host environment is 64 bit currently and it is not possible to migrate the whole environment to 32 bit. I am happy to explain the details if needed, but I would love you to trust me about that. =) So, is it possible to say more than just DEPENDS = ncurses-native, something like DEPENDS = ncurses-native:x86 or something? Cheers, L. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain
Come on, Yocto maintainers, please... Mark sent this change relatively long ago, and it is still in new state, sadly. The current SDK shipped _breaks_ any third-party software that uses standard python with regards to the libraries and all that. This is is slightly frustrating. We also face the same issue. :( On Mon, Aug 11, 2014 at 7:26 PM, Marek Vasut ma...@denx.de wrote: On Monday, August 11, 2014 at 12:26:34 PM, Richard Purdie wrote: On Fri, 2014-08-08 at 14:22 +0200, Marek Vasut wrote: On Friday, August 08, 2014 at 07:22:04 AM, Koen Kooi wrote: Since 'yocto' is a project like freedesktop.org your commit message doesn't make sense, it should be something like: meta-toolchain-qt: Install full set of python modules Got it, Saul also told me so. I will wait a bit for some more feedback and repost with corrections, OK ? Is this approach I took here even correct please ? I'd really like to see a packagegroup defined somewhere with this list of python modules which the various recipes can then reference... I agree, that makes sense. Is this approach I took here the correct one please ? Best regards, Marek Vasut -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain
I meant to write Marek. I apologize for the spelling issue. On Thu, Sep 18, 2014 at 10:11 AM, Laszlo Papp lp...@kde.org wrote: Come on, Yocto maintainers, please... Mark sent this change relatively long ago, and it is still in new state, sadly. The current SDK shipped _breaks_ any third-party software that uses standard python with regards to the libraries and all that. This is is slightly frustrating. We also face the same issue. :( On Mon, Aug 11, 2014 at 7:26 PM, Marek Vasut ma...@denx.de wrote: On Monday, August 11, 2014 at 12:26:34 PM, Richard Purdie wrote: On Fri, 2014-08-08 at 14:22 +0200, Marek Vasut wrote: On Friday, August 08, 2014 at 07:22:04 AM, Koen Kooi wrote: Since 'yocto' is a project like freedesktop.org your commit message doesn't make sense, it should be something like: meta-toolchain-qt: Install full set of python modules Got it, Saul also told me so. I will wait a bit for some more feedback and repost with corrections, OK ? Is this approach I took here even correct please ? I'd really like to see a packagegroup defined somewhere with this list of python modules which the various recipes can then reference... I agree, that makes sense. Is this approach I took here the correct one please ? Best regards, Marek Vasut -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain
On Thu, Sep 18, 2014 at 10:16 AM, Marek Vasut ma...@denx.de wrote: On Thursday, September 18, 2014 at 11:11:45 AM, Laszlo Papp wrote: Come on, Yocto maintainers, please... Mark sent this change relatively long ago, and it is still in new state, sadly. The current SDK shipped _breaks_ any third-party software that uses standard python with regards to the libraries and all that. This is is slightly frustrating. We also face the same issue. :( Thanks for the reminder, new version which should fix the issues with the previous one is on the ML now. You're all on CC. I do not think this is an explicit Qt issue, and hence fixing on that layer sounds like a weird approach. It seems to be a generic python issue and so, I think it should be addressed in its core. I opened a new report for this: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6735 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add support for ccache builds with the SDK
On Tue, Sep 2, 2014 at 7:22 AM, Fathi Boudra fathi.bou...@linaro.org wrote: On 1 September 2014 21:04, Otavio Salvador ota...@ossystems.com.br wrote: Laszlo, On Mon, Sep 1, 2014 at 2:47 PM, Laszlo Papp lp...@kde.org wrote: Just in case the severity is not clear. Without this change, the Yocto SDK breaks the build for our software since we do prefer to use ccache for speeding the build process up. We are probably not alone with that ... Saul request is very valid. He is asking you to conform to the commit guidelines we use and it is no-sense you to expect that he or someone else does this for you. So I think if you expect this to be merged you need to fix and send a v2. fwiw, we've been hit by this maintainers behavior. Several patches are stuck in the queue after 10 days of non-activity, followed up by a nitpick comment. It's a source of frustration for the submitter and is killing his motivation. Such comment could come earlier, while he's in the heat of the action and he's usually more receptive to the review. As a result, we lose a contribution. The project/maintainer/submitter/end-user doesn't benefit from the contribution. my 2cts. Thanks for trying to get things done, Fathi. I appreciate it. I also understand what Richard was writing that they are busy. Sure, I am very busy, too, but not helping others to get involved easily will leave more burden on them in the long run, sadly. This is not the first time that I have to follow changes for relatively long time, and the patch in the end does not get in, even when it fails build failures for end users, like this one. The last long bikeshed was around the busybox-ntp. Since I keep patching our Yocto fork, I thought after a while, let us give it a try again with a simple thing, and it went as far as this, only after follow-ups 1-2 weeks later. It is probably needless to say, but I feel personally very difficult to get involved in the Yocto project and I am not saying it because there are cosmetic changes with my patches. That is a good level if it is just cosmetic in a newcomer's patch anyway? I am just trying to write that as someone who is working for a very small company, I do not have time for all superfluous perfectionism this project tries to follow. I appreciate, but I cannot cope with it. My highest responsibility is to get things done and ship products. That does not include cosmetic nitpicking in a small company. It might be OK for Google, Intel, Linux Foundation, etc, but this is simply not any priority when you need to work on getting proper income for your family. Why I am personally a little bit frustrated unfortunately it is not because things like this happen, but that it happens in a row. The Yocto users are still screwed for using ntp properly with busybox. That change also went to /dev/null due to some irrelevant thing. What is worse, someone even wrote me in person that it is a shame it did not get in since that person would have also needed the feature. As far as I am concerned, the Yocto project contribution is currently unsuitable for small companies and individuals whose highest responsibility is to get income, i.e. caring about sustainable features rather than nitpicks. I have been on both sides, and I can understand when someone is maximalist. It is very difficult to understand others in the state of mind; been there, done that. Anyway, I have a relatively long list of unintegrated features into Yocto by now, but this is not quite good that they are going on their own way in a fork rather than going in. As it was written in this thread, it is quite demotivating to see such nitpicks after 1-2 weeks, and then long discussions about who is doing what. I can assure you that if I had not had several changes rejected due to such nitpicks, I would have already fixed this one, but in this case, I am not doing them anymore since I do not see any willingness from the Yocto community to try to help me with getting things easily in. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add support for ccache builds with the SDK
It is indeed nit, and not something I wishfully spend my time with, so
feel free to rewrite the commit message and integrate the ccache
support. As usual, this feature is also applied in our fork, so I am
fine... It is only the upstream Yocto users who may be missing
features out.
Having said that, thank you for your feedback.
On Fri, Aug 29, 2014 at 7:29 PM, Saul Wold s...@linux.intel.com wrote:
Might be a nit, but can you please follow the Commit Guildlines at
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
The summary should include the filename or area of the fix
toolchain-script: Add ...
Also can you expand on the why this is needed?
Thanks
Sau!
On 08/22/2014 08:20 AM, Laszlo Papp wrote:
Signed-off-by: Laszlo Papp lp...@kde.org
---
meta/classes/toolchain-scripts.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index 6cc8eba..60278d6 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () {
EXTRAPATH=$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i
done
echo 'export
PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH'
$script
+ echo 'export
CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH'
$script
echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' $script
echo 'export
PKG_CONFIG_PATH=$SDKTARGETSYSROOT'$libdir'/pkgconfig' $script
echo 'export
CONFIG_SITE=${SDKPATH}/site-config-'${multimach_target_sys} $script
@@ -37,6 +38,7 @@ toolchain_create_tree_env_script () {
rm -f $script
touch $script
echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}'
$script
+ echo 'export
CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}' $script
echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}'
$script
echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' $script
echo 'export CONFIG_SITE=${@siteinfo_get_files(d)}' $script
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add support for ccache builds with the SDK
Just in case the severity is not clear. Without this change, the Yocto
SDK breaks the build for our software since we do prefer to use ccache
for speeding the build process up. We are probably not alone with that
...
On Mon, Sep 1, 2014 at 6:34 PM, Laszlo Papp lp...@kde.org wrote:
It is indeed nit, and not something I wishfully spend my time with, so
feel free to rewrite the commit message and integrate the ccache
support. As usual, this feature is also applied in our fork, so I am
fine... It is only the upstream Yocto users who may be missing
features out.
Having said that, thank you for your feedback.
On Fri, Aug 29, 2014 at 7:29 PM, Saul Wold s...@linux.intel.com wrote:
Might be a nit, but can you please follow the Commit Guildlines at
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
The summary should include the filename or area of the fix
toolchain-script: Add ...
Also can you expand on the why this is needed?
Thanks
Sau!
On 08/22/2014 08:20 AM, Laszlo Papp wrote:
Signed-off-by: Laszlo Papp lp...@kde.org
---
meta/classes/toolchain-scripts.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index 6cc8eba..60278d6 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () {
EXTRAPATH=$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i
done
echo 'export
PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH'
$script
+ echo 'export
CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH'
$script
echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' $script
echo 'export
PKG_CONFIG_PATH=$SDKTARGETSYSROOT'$libdir'/pkgconfig' $script
echo 'export
CONFIG_SITE=${SDKPATH}/site-config-'${multimach_target_sys} $script
@@ -37,6 +38,7 @@ toolchain_create_tree_env_script () {
rm -f $script
touch $script
echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}'
$script
+ echo 'export
CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}' $script
echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}'
$script
echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' $script
echo 'export CONFIG_SITE=${@siteinfo_get_files(d)}' $script
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] ptest-runner: return 1 instead of zero if any test fails
On Mon, Aug 25, 2014 at 7:42 AM, Stoicescu, CorneliuX corneliux.stoice...@intel.com wrote: Hello, From my experience with ptest, there will always be a few tests failing, so we will always get exit code 1. Ptest is not only about meta-core, you need to remember that. My use case is actually quite different: running ptest only on my binaries, and I will trust the rest of the system. For me, it is critical to see if there is any issues in my system. This patch resolves that use case, but even for Yocto, you really oughta aim for fixing your tests, either with known failure or correct means. Should this better return exit code 0 if the individual tests performed correctly(weather they passed or failed) and 1 if there were any errors during the running of the tests? I do not understand this question. This is what the current change tries to do. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add support for ccache builds with the SDK
One week passed and there is neither feedback, nor progress. What am I
doing wrong?
On Fri, Aug 22, 2014 at 4:20 PM, Laszlo Papp lp...@kde.org wrote:
Signed-off-by: Laszlo Papp lp...@kde.org
---
meta/classes/toolchain-scripts.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index 6cc8eba..60278d6 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () {
EXTRAPATH=$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i
done
echo 'export
PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH'
$script
+ echo 'export
CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH'
$script
echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' $script
echo 'export PKG_CONFIG_PATH=$SDKTARGETSYSROOT'$libdir'/pkgconfig'
$script
echo 'export
CONFIG_SITE=${SDKPATH}/site-config-'${multimach_target_sys} $script
@@ -37,6 +38,7 @@ toolchain_create_tree_env_script () {
rm -f $script
touch $script
echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' $script
+ echo 'export
CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}' $script
echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}'
$script
echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' $script
echo 'export CONFIG_SITE=${@siteinfo_get_files(d)}' $script
--
2.0.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Add support for ccache builds with the SDK
Signed-off-by: Laszlo Papp lp...@kde.org
---
meta/classes/toolchain-scripts.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index 6cc8eba..60278d6 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () {
EXTRAPATH=$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i
done
echo 'export
PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH'
$script
+ echo 'export
CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH'
$script
echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' $script
echo 'export PKG_CONFIG_PATH=$SDKTARGETSYSROOT'$libdir'/pkgconfig'
$script
echo 'export
CONFIG_SITE=${SDKPATH}/site-config-'${multimach_target_sys} $script
@@ -37,6 +38,7 @@ toolchain_create_tree_env_script () {
rm -f $script
touch $script
echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' $script
+ echo 'export CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}'
$script
echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}'
$script
echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' $script
echo 'export CONFIG_SITE=${@siteinfo_get_files(d)}' $script
--
2.0.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Adding cgdb to meta
On Mon, Aug 11, 2014 at 1:21 PM, Burton, Ross ross.bur...@intel.com wrote: On 11 August 2014 12:35, Laszlo Papp lp...@kde.org wrote: So, instead of different developers maintaining this in their own layer, how about including it in meta? I'd suggest sending a recipe to meta-oe. That layer is too big. It is nearly everything that is rejected from meta; ok there are some dedicated layers, like meta-networking, but it feels like the last resort shelter where everything can just be thrown at. I do not think it is just us who do not wanna pull it into their project. Never mind, it remains to be a feature in our layer, which is closed source, then. It is a pity, but I will move along. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Adding cgdb to meta
On Tue, Aug 12, 2014 at 4:48 PM, Burton, Ross ross.bur...@intel.com wrote: On 12 August 2014 16:46, Laszlo Papp lp...@kde.org wrote: That layer is too big. It is nearly everything that is rejected from meta; ok there are some dedicated layers, like meta-networking, but it feels like the last resort shelter where everything can just be thrown at. I do not think it is just us who do not wanna pull it into their project. Never mind, it remains to be a feature in our layer, which is closed source, then. It is a pity, but I will move along. People who think its too big are welcome to copy recipes out of it and sync them manually - that's still better than not sharing the recipe. I am unfortunately not interested in participating to something that I have no intent to even test myself before submitting. meta-oe became a monster can which I personally would not like to deal with. That is said with due-respect. If its goal were reconsidered and split into several small layers, then mayhaps... But it is not there, and I am not sure if it was any soon... Unfortunately, this feature remains proprietary at the point of writing this. As long as it works for me, I will not be too much bothered, although I feel sorry for those who will need to reinvent the recipe, modulo stabilization. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Adding cgdb to meta
On Tue, Aug 12, 2014 at 4:51 PM, Laszlo Papp lp...@kde.org wrote: On Tue, Aug 12, 2014 at 4:48 PM, Burton, Ross ross.bur...@intel.com wrote: On 12 August 2014 16:46, Laszlo Papp lp...@kde.org wrote: That layer is too big. It is nearly everything that is rejected from meta; ok there are some dedicated layers, like meta-networking, but it feels like the last resort shelter where everything can just be thrown at. I do not think it is just us who do not wanna pull it into their project. Never mind, it remains to be a feature in our layer, which is closed source, then. It is a pity, but I will move along. People who think its too big are welcome to copy recipes out of it and sync them manually - that's still better than not sharing the recipe. I am unfortunately not interested in participating to something that I have no intent to even test myself before submitting. meta-oe became a monster can which I personally would not like to deal with. That is said with due-respect. If its goal were reconsidered and split into several small layers, then mayhaps... But it is not there, and I am not sure if it was any soon... Unfortunately, this feature remains proprietary at the point of writing this. As long as it works for me, I will not be too much bothered, although I feel sorry for those who will need to reinvent the recipe, modulo stabilization. But that is alright as long as everyone else finds the IMHO cumbersome workflow with gdb OK for debugging. I think pleasant debugging is very important for developers, and cgdb is still a command line based tool, basically a thing wrapper on top of gdb with ncurses. It is not like ddd and other heavy tools. That is why I thought with minor addition, meta could be increase the software development experience; gdb is just way too raw to be effective. But again, no one else might share this opinion, so let us move on. Here is a reminder screenshot for those who do not know it, just in case: http://cgdb.github.io/images/screenshot_debugging.png -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Adding cgdb to meta
On Tue, Aug 12, 2014 at 4:55 PM, Laszlo Papp lp...@kde.org wrote: On Tue, Aug 12, 2014 at 4:51 PM, Laszlo Papp lp...@kde.org wrote: On Tue, Aug 12, 2014 at 4:48 PM, Burton, Ross ross.bur...@intel.com wrote: On 12 August 2014 16:46, Laszlo Papp lp...@kde.org wrote: That layer is too big. It is nearly everything that is rejected from meta; ok there are some dedicated layers, like meta-networking, but it feels like the last resort shelter where everything can just be thrown at. I do not think it is just us who do not wanna pull it into their project. Never mind, it remains to be a feature in our layer, which is closed source, then. It is a pity, but I will move along. People who think its too big are welcome to copy recipes out of it and sync them manually - that's still better than not sharing the recipe. I am unfortunately not interested in participating to something that I have no intent to even test myself before submitting. meta-oe became a monster can which I personally would not like to deal with. That is said with due-respect. If its goal were reconsidered and split into several small layers, then mayhaps... But it is not there, and I am not sure if it was any soon... Unfortunately, this feature remains proprietary at the point of writing this. As long as it works for me, I will not be too much bothered, although I feel sorry for those who will need to reinvent the recipe, modulo stabilization. But that is alright as long as everyone else finds the IMHO cumbersome workflow with gdb OK for debugging. I think pleasant debugging is very important for developers, and cgdb is still a command line based tool, basically a thing wrapper on top of gdb with ncurses. It is not like ddd and other heavy tools. That is why I thought with minor addition, meta could be increase the software development experience; gdb is just way too raw to be effective. But again, no one else might share this opinion, so let us move on. Here is a reminder screenshot for those who do not know it, just in case: http://cgdb.github.io/images/screenshot_debugging.png Alternatively, feel free to advise any sufficient debugging experience with oe-core. I will happily switch to any opportunities that reach this level. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Adding cgdb to meta
Hi, is it just me who uses cgdb on the host (or the target) for debugging? Gdb is semi-painful by default because you always need to list things, cannot really browse the code easily, etc. It is also black and white, so the source code syntax does not necessarily stand out for helping. So, instead of different developers maintaining this in their own layer, how about including it in meta? Since it is a host side thing (or it could be target, too) and debugging, it would not bloat the target images that much. It is just an ncurses based frontend, but it is great! Cheers, L. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add init script (sysv) support for busybox's ntpd
Any reason why this feature has never got in? It was submitted more than five months ago, and it would have added some feature to the system even if not _everything_ right from the beginning? On Sat, Mar 22, 2014 at 2:03 PM, Laszlo Papp lp...@kde.org wrote: On Fri, Mar 21, 2014 at 2:39 PM, Martin Jansa martin.ja...@gmail.com wrote: On Fri, Mar 21, 2014 at 01:59:15PM +, Laszlo Papp wrote: On Thu, Mar 20, 2014 at 7:59 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 March 2014 19:01, Laszlo Papp lp...@kde.org wrote: This init script is adding support for sysv and no more. This is also indicated in the first line of the commit message. I am sorry, but I will not test it systemd and with other systems You're not being asked to test with systemd. You're being asked to add LSB-standard sysvinit-specific headers to a sysvinit script. In my understanding, people were referring to two issues: 1) not working with systemd and what not compat modes. This is not something I will test any soon. Other people already know it's causing the issues without LSB headers, so if you just add them, you don't need to test it with systemd, other people who care about systemd will do that for you or at least be OK with adding this script, because it will have LSB headers (so it should work fine in systemd world). If someone is really interested in systemd, et al, unlike me at this point, I guess it is not a big deal to get an LSB header from someone to get it integrated into my change? If no one cares about that, then why bother? So, if someone sends this to me I will integrate it, otherwise there is no point since that means no one cares. But then again, this should not still block the change as it can be added incrementally. I am not sure if it is a good idea to block a feature because it does not provide another feature, too. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add init script (sysv) support for busybox's ntpd
On Fri, Mar 21, 2014 at 2:39 PM, Martin Jansa martin.ja...@gmail.com wrote: On Fri, Mar 21, 2014 at 01:59:15PM +, Laszlo Papp wrote: On Thu, Mar 20, 2014 at 7:59 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 March 2014 19:01, Laszlo Papp lp...@kde.org wrote: This init script is adding support for sysv and no more. This is also indicated in the first line of the commit message. I am sorry, but I will not test it systemd and with other systems You're not being asked to test with systemd. You're being asked to add LSB-standard sysvinit-specific headers to a sysvinit script. In my understanding, people were referring to two issues: 1) not working with systemd and what not compat modes. This is not something I will test any soon. Other people already know it's causing the issues without LSB headers, so if you just add them, you don't need to test it with systemd, other people who care about systemd will do that for you or at least be OK with adding this script, because it will have LSB headers (so it should work fine in systemd world). If someone is really interested in systemd, et al, unlike me at this point, I guess it is not a big deal to get an LSB header from someone to get it integrated into my change? If no one cares about that, then why bother? So, if someone sends this to me I will integrate it, otherwise there is no point since that means no one cares. But then again, this should not still block the change as it can be added incrementally. I am not sure if it is a good idea to block a feature because it does not provide another feature, too. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add init script (sysv) support for busybox's ntpd
On Thu, Mar 20, 2014 at 7:59 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 March 2014 19:01, Laszlo Papp lp...@kde.org wrote: This init script is adding support for sysv and no more. This is also indicated in the first line of the commit message. I am sorry, but I will not test it systemd and with other systems You're not being asked to test with systemd. You're being asked to add LSB-standard sysvinit-specific headers to a sysvinit script. In my understanding, people were referring to two issues: 1) not working with systemd and what not compat modes. This is not something I will test any soon. 2) It is not consistent, whereas if I take a look into busybox, the consistency is what I do, apparently. I would like to quote from the Fedora wiki for instance: LSB Headers are not required for Fedora SysV-style initscripts, but they may be used. There is no requirement in the LSB certification for any system scripts to be LSB compliant, and it can cause issues with ordering. So what is wrong about it without systemd and other compat modes? If it is that big a deal (i.e. blocker), perhaps it is better to document it in the contribution guideline as a generic trap. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add init script (sysv) support for busybox's ntpd
On Thu, Mar 20, 2014 at 10:45 AM, Burton, Ross ross.bur...@intel.com wrote: On 20 March 2014 03:26, Laszlo Papp lp...@kde.org wrote: +PEER=127.0.0.1 That doesn't seem like a very useful default. We also can't use the NTP pool by default, so this should copy the behaviour of the ntpd package in meta-networking and default to no peers, and not start if none are specified. Yeah, some real timeserver could be put behind comments. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add init script (sysv) support for busybox's ntpd
On Thu, Mar 20, 2014 at 11:22 AM, Koen Kooi k...@dominion.thruhere.net wrote: Op 20 mrt. 2014, om 11:45 heeft Burton, Ross ross.bur...@intel.com het volgende geschreven: On 20 March 2014 03:26, Laszlo Papp lp...@kde.org wrote: +PEER=127.0.0.1 That doesn't seem like a very useful default. We also can't use the NTP pool by default, so this should copy the behaviour of the ntpd package in meta-networking and default to no peers, and not start if none are specified. And the initscript is missing LSB headers. Just like the other similar scripts. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add init script (sysv) support for busybox's ntpd
On Thu, Mar 20, 2014 at 11:59 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Thu, Mar 20, 2014 at 8:34 AM, Laszlo Papp lp...@kde.org wrote: On Thu, Mar 20, 2014 at 11:22 AM, Koen Kooi k...@dominion.thruhere.net wrote: Op 20 mrt. 2014, om 11:45 heeft Burton, Ross ross.bur...@intel.com het volgende geschreven: On 20 March 2014 03:26, Laszlo Papp lp...@kde.org wrote: +PEER=127.0.0.1 That doesn't seem like a very useful default. We also can't use the NTP pool by default, so this should copy the behaviour of the ntpd package in meta-networking and default to no peers, and not start if none are specified. And the initscript is missing LSB headers. Just like the other similar scripts. This does not mean we ought to make the problem worse so add it for new ones. If you are in good mood, send a fix for the others too ;) I do not think this is a problem. Could you please point out what functionality it breaks? Send patches for the others, and I will make this cosmetic change for this one, too. Consistency is more important than a mess of different styles, especially when it comes to cosmetic changes like this. That said, Ross had a good point - although that is not critical either, and since everyone is overriding the default, it could work without that - , so I will update that one. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add init script (sysv) support for busybox's ntpd
On Thu, Mar 20, 2014 at 12:26 PM, Otavio Salvador ota...@ossystems.com.br wrote: On Thu, Mar 20, 2014 at 9:16 AM, Laszlo Papp lp...@kde.org wrote: On Thu, Mar 20, 2014 at 11:59 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Thu, Mar 20, 2014 at 8:34 AM, Laszlo Papp lp...@kde.org wrote: On Thu, Mar 20, 2014 at 11:22 AM, Koen Kooi k...@dominion.thruhere.net wrote: Op 20 mrt. 2014, om 11:45 heeft Burton, Ross ross.bur...@intel.com het volgende geschreven: On 20 March 2014 03:26, Laszlo Papp lp...@kde.org wrote: +PEER=127.0.0.1 That doesn't seem like a very useful default. We also can't use the NTP pool by default, so this should copy the behaviour of the ntpd package in meta-networking and default to no peers, and not start if none are specified. And the initscript is missing LSB headers. Just like the other similar scripts. This does not mean we ought to make the problem worse so add it for new ones. If you are in good mood, send a fix for the others too ;) I do not think this is a problem. Could you please point out what functionality it breaks? Send patches for the others, and I will make this cosmetic change for this one, too. Consistency is more important than a mess of different styles, especially when it comes to cosmetic changes like this. Koen and I think it is important. So consider this my NACK for the patch as is. You are free to NACK without an explanation why it is important, but do not expect it to weigh much that way, at least in my eyes, based on that you are not even a maintainer as far as I know. I also think that it is not constructive to give NACK without answering the questions, and only telling again It is important. Please be more constructive and explain the real issue. That is a better way of convincing a contributor than telling the person it is bad what you are doing because it is bad. There was someone today publishing a blog post how important it is to become pragmatic to get things done. Currently, cosmetic changes are just in the way of getting things done. The feature shall be more important than cosmetic changes. I saw this frightening away contributors, and features actually not getting into projects. That being said, if you can explain your reasoning, and I find it reasonable and worthy, I will update it. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add init script (sysv) support for busybox's ntpd
On Thu, Mar 20, 2014 at 1:28 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 March 2014 12:44, Laszlo Papp lp...@kde.org wrote: You are free to NACK without an explanation why it is important, but do not expect it to weigh much that way, at least in my eyes, based on that you are not even a maintainer as far as I know. One good reason: systemd reads the LSB headers. This init script is for SysV, not systemd. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add init script (sysv) support for busybox's ntpd
What is actually probably a bigger issue than the LSB, is that the conf is currently sourced. That means if it contains an rm -rf / statement, it will execute it. Perhaps, this should be solved more gently... -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add init script (sysv) support for busybox's ntpd
On Thu, Mar 20, 2014 at 4:28 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 20 mrt. 2014, om 14:28 heeft Burton, Ross ross.bur...@intel.com het volgende geschreven: On 20 March 2014 12:44, Laszlo Papp lp...@kde.org wrote: You are free to NACK without an explanation why it is important, but do not expect it to weigh much that way, at least in my eyes, based on that you are not even a maintainer as far as I know. One good reason: systemd reads the LSB headers. As well as other inits that support sysv mode. This init script is adding support for sysv and no more. This is also indicated in the first line of the commit message. I am sorry, but I will not test it systemd and with other systems. You are free to test it with everything in the world out there, and provide a more intelligent change and void my work. This is what I call not pragmatic. It is not like incremental improvement is not useful because it does not do all the things in the world right away. This is clearly communicated in the commit message what it is for. For SysV, this is not any problem, it works fine. No one has revealed a real issue with that so far as far as I can tell. So why block a feature that was meant for something just because someone cannot test on everything and/or does not want? What is being read here in my understand is, everything or nothing. This is not pragmatic. Please notice that perfection is the enemy of good. So my bottom line, feel free to reject this feature in favor of having nothing instead of something. Unless someone can come up with a rebuttal that it is not working for the intended and documentation use case, I am not willing to change it, sorry. It would be pointless because I could not test it anyway, and I will not send blind changes like that. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Add init script (sysv) support for busybox's ntpd
---
meta/recipes-core/busybox/busybox.inc | 10 --
meta/recipes-core/busybox/busybox_1.22.1.bb | 2 ++
meta/recipes-core/busybox/files/busybox-ntpd | 39 +++
meta/recipes-core/busybox/files/busybox-ntpd.conf | 1 +
4 files changed, 50 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-core/busybox/files/busybox-ntpd
create mode 100644 meta/recipes-core/busybox/files/busybox-ntpd.conf
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index 69b9b0c..653ab16 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -18,7 +18,7 @@ BUSYBOX_SPLIT_SUID ?= 1
export EXTRA_CFLAGS = ${CFLAGS}
export EXTRA_LDFLAGS = ${LDFLAGS}
-PACKAGES =+ ${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev
${PN}-hwclock
+PACKAGES =+ ${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev
${PN}-hwclock ${PN}-ntpd
FILES_${PN}-httpd = ${sysconfdir}/init.d/busybox-httpd /srv/www
FILES_${PN}-syslog = ${sysconfdir}/init.d/syslog*
${sysconfdir}/syslog-startup.conf* ${sysconfdir}/syslog.conf*
${systemd_unitdir}/system/syslog.service ${sysconfdir}/default/busybox-syslog
@@ -26,8 +26,9 @@ FILES_${PN}-mdev = ${sysconfdir}/init.d/mdev
${sysconfdir}/mdev.conf
FILES_${PN}-udhcpd = ${sysconfdir}/init.d/busybox-udhcpd
FILES_${PN}-udhcpc = ${sysconfdir}/udhcpc.d ${datadir}/udhcpc
FILES_${PN}-hwclock = ${sysconfdir}/init.d/hwclock.sh
+FILES_${PN}-ntpd = ${sysconfdir}/init.d/busybox-ntpd
${sysconfdir}/busybox-ntpd.conf
-INITSCRIPT_PACKAGES = ${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev
${PN}-hwclock
+INITSCRIPT_PACKAGES = ${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev
${PN}-hwclock ${PN}-ntpd
INITSCRIPT_NAME_${PN}-httpd = busybox-httpd
INITSCRIPT_NAME_${PN}-hwclock = hwclock.sh
@@ -35,6 +36,7 @@ INITSCRIPT_NAME_${PN}-mdev = mdev
INITSCRIPT_PARAMS_${PN}-mdev = start 03 S .
INITSCRIPT_NAME_${PN}-syslog = syslog
INITSCRIPT_NAME_${PN}-udhcpd = busybox-udhcpd
+INITSCRIPT_NAME_${PN}-ntpd = busybox-ntpd
SYSTEMD_PACKAGES = ${PN}-syslog
SYSTEMD_SERVICE_${PN}-syslog = busybox-syslog.service
@@ -264,6 +266,10 @@ do_install () {
install -m 644 ${WORKDIR}/mdev.conf
${D}${sysconfdir}/mdev.conf
fi
fi
+if grep CONFIG_NTPD=y ${B}/.config; then
+ install -m 0755 ${WORKDIR}/busybox-ntpd
${D}${sysconfdir}/init.d/
+ install -m 0644 ${WORKDIR}/busybox-ntpd.conf ${D}${sysconfdir}/
+ fi
if ${@base_contains('DISTRO_FEATURES','systemd','true','false',d)}; then
install -d ${D}${systemd_unitdir}/system
diff --git a/meta/recipes-core/busybox/busybox_1.22.1.bb
b/meta/recipes-core/busybox/busybox_1.22.1.bb
index ffc9435..c513aa2 100644
--- a/meta/recipes-core/busybox/busybox_1.22.1.bb
+++ b/meta/recipes-core/busybox/busybox_1.22.1.bb
@@ -27,6 +27,8 @@ SRC_URI =
http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://inetd.conf \
file://inetd \
file://login-utilities.cfg \
+ file://busybox-ntpd \
+ file://busybox-ntpd.conf \
SRC_URI[tarball.md5sum] = 337d1a15ab1cb1d4ed423168b1eb7d7e
diff --git a/meta/recipes-core/busybox/files/busybox-ntpd
b/meta/recipes-core/busybox/files/busybox-ntpd
new file mode 100644
index 000..e558973
--- /dev/null
+++ b/meta/recipes-core/busybox/files/busybox-ntpd
@@ -0,0 +1,39 @@
+#!/bin/sh
+DAEMON=/sbin/ntpd
+NAME=ntpd
+DESC=Busybox NTP Daemon
+source /etc/busybox-ntpd.conf
+ARGS=-p $PEER
+
+test -f $DAEMON || exit 0
+
+set -e
+
+case $1 in
+start)
+start-stop-daemon -S -b -n $NAME -a $DAEMON -- $ARGS
+echo done.
+;;
+stop)
+echo -n stopping $DESC: $NAME...
+start-stop-daemon -K -n $NAME
+echo done.
+;;
+restart)
+echo restarting $DESC: $NAME...
+$0 stop
+$0 start
+echo done.
+;;
+reload)
+echo -n reloading $DESC: $NAME...
+killall -HUP $(basename ${DAEMON})
+echo done.
+;;
+*)
+echo Usage: $0 {start|stop|restart|reload}
+exit 1
+;;
+esac
+
+exit 0
diff --git a/meta/recipes-core/busybox/files/busybox-ntpd.conf
b/meta/recipes-core/busybox/files/busybox-ntpd.conf
new file mode 100644
index 000..65665d8
--- /dev/null
+++ b/meta/recipes-core/busybox/files/busybox-ntpd.conf
@@ -0,0 +1 @@
+PEER=127.0.0.1
--
1.9.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] No versioning for existing images
On Tue, Feb 25, 2014 at 7:22 AM, Anders Darander and...@chargestorm.se wrote: Well, if you set it as a variable, you can always use it in e.g. the IMAGE_PREPROCESS_COMMAND, to store it to a suitable file in the image. Just as I'm storing the output from git describe. This makes me think that it would be nice to have a dedicated variable for this version that automatically populates a standard place, e.g. /etc/version. That could standardize this process across projects, although it could be made customizable on top of the default if one wishes to do it differently. So, how about an IMAGE_VERSION variable which would be put into the image name if specified, and the string would also be put into some place on the target, like /etc/version? If you plan on keeping multiple image versions (which you should do at least for released images), you likely should then append your version number to the image names (and possibly some more info), or at least store them in a versioned tree/repository for easy retrieval. Yes, I agree that version numbers should be put into the image name. Yes, a versioned tree makes sense, which I think we can call a mirror for instance. I think that is enough for binaries, and perhaps it is better than a separate versioned repository on top of the already existing tags. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Conf notes
On Mon, Feb 24, 2014 at 6:34 AM, Nicolas Dechesne
nicolas.deche...@linaro.org wrote:
On Fri, Feb 21, 2014 at 8:06 PM, Laszlo Papp lp...@kde.org wrote:
I have just put a conf notes file into my own layer, but when I source
the oe-init-build-env script, I am still getting the notes from Yocto
rather than my customized.
What am I doing wrong? I see this in the ./scripts/oe-setup-builddir file:
TEMPLATECONF=${TEMPLATECONF:-meta-yocto/conf}
and other references, but I have not pin the issue down just yet.
are you setting TEMPLATECONF variable? if so, how?
cat setup.sh
#!/bin/bash
TEMPLATECONF=meta-foo/conf . oe-init-build-env
also, if you provide conf-notes.txt you need to provide
local.conf.sample and bblayers.conf.sample.
if TEMPLATECONF is set, it will use these files:
OECORELAYERCONF=$TEMPLATECONF/bblayers.conf.sample
OECORELOCALCONF=$TEMPLATECONF/local.conf.sample
OECORENOTESCONF=$TEMPLATECONF/conf-notes.txt
ls ./meta-foo/conf/
bblayers.conf.sample conf-notes.txt distro layer.conf
local.conf.sample site.conf.sample
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Conf notes
On Mon, Feb 24, 2014 at 10:28 AM, Nicolas Dechesne nicolas.deche...@linaro.org wrote: On Mon, Feb 24, 2014 at 10:35 AM, Laszlo Papp lp...@kde.org wrote: are you setting TEMPLATECONF variable? if so, how? cat setup.sh #!/bin/bash TEMPLATECONF=meta-foo/conf . oe-init-build-env hmm. do you get any error message? Nope, I have been using this construction for several weeks now. The local and bblayer samples have been extracted properly into the build folder, so in that sense, there is no infrastructural change introduced in here, just yet another file added in the folder. meta-foo needs to be a folder in OEROOT (along with 'meta' folder), or TEMPLATECONF can be an absolute path otherwise, as you can see from this code snippet (from oe-setup-builddir) Yes, meta-foo is beside meta. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] No versioning for existing images
Hi, I was wondering why existing images would not have version numbers attached. Say, we have a core-image-minimal image, but from the recipe, it is not possible which image version it is. Perhaps, it is just my ignorance and lack of understand, but for the moment, it seems to be an important information for e.g. distribution vendors and image creators to have an image version and the corresponding packages and versions attached to that particular version. It is easier to do a software upgrade then if you wish to do that based on the information of a certain image variant. I mean, it will lead to more manageable and reproducable images. It is possible that I am not aware of something important, so please enlighten me. It would be nice to see how other OE users do a system upgrade. For instance, the MeeGo Nokia phone had a software version information in the settings, and that is something I would personally consider as the image version, but again, there might be better ways. Please share good practices in here., or alternatively, feel free to point me to any documentation, examples, etc. Cheers, L. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Conf notes
On Mon, Feb 24, 2014 at 12:49 PM, Nicolas Dechesne nicolas.deche...@linaro.org wrote: On Mon, Feb 24, 2014 at 12:47 PM, Laszlo Papp lp...@kde.org wrote: hmm. do you get any error message? Nope, I have been using this construction for several weeks now. The local and bblayer samples have been extracted properly into the build folder, so in that sense, there is no infrastructural change introduced in here, just yet another file added in the folder. well, i don't see what can possibly go wrong then... especially if layers.conf.sample and bblayer sample files work fine... maybe adding set -x in the script would reveal something.. 1) I use dylan if that matters. 2) cat ../meta-foo/conf/conf-notes.txt Common targets are: core-image-minimal foo You can also run generated qemu images with a command like 'runqemu qemux86' 3) set -x output ++ TEMPLATECONF=meta-foo/conf ++ . oe-init-build-env +++ '[' -z '' ']' +++ '[' xbash = x./oe-init-build-env ']' +++ '[' -n oe-init-build-env ']' dirname oe-init-build-env +++ OEROOT=. readlink -f . +++ OEROOT=/home/lpapp/Projects/Yocto/poky-dylan-9.0.1 +++ export OEROOT +++ . /home/lpapp/Projects/Yocto/poky-dylan-9.0.1/scripts/oe-buildenv-internal '[' -z /home/lpapp/Projects/Yocto/poky-dylan-9.0.1 ']' '[' x = x ']' '[' x = x ']' BDIR=build expr build : '/.*' + pwd BUILDDIR=/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build unset BDIR BITBAKEDIR=/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/bitbake/ + readlink -f /home/lpapp/Projects/Yocto/poky-dylan-9.0.1/bitbake/ BITBAKEDIR=/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/bitbake + readlink -f /home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build BUILDDIR=/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build test -d /home/lpapp/Projects/Yocto/poky-dylan-9.0.1/bitbake PATH=/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/scripts:/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/bitbake/bin/:/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/scripts:/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/bitbake/bin/:/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/scripts:/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/bitbake/bin/:/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/scripts:/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/bitbake/bin/:/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/scripts:/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/bitbake/bin/:/usr/lib/colorgcc/bin/:/home/lpapp/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games unset BITBAKEDIR export BUILDDIR export PATH export 'BB_ENV_EXTRAWHITE=MACHINE DISTRO TCMODE TCLIBC http_proxy ftp_proxy https_proxy all_proxy ALL_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY SDKMACHINE BB_NUMBER_THREADS PARALLEL_MAKE GIT_PROXY_COMMAND GIT_PROXY_IGNORE SOCKS5_PASSWD SOCKS5_USER' BB_ENV_EXTRAWHITE='MACHINE DISTRO TCMODE TCLIBC http_proxy ftp_proxy https_proxy all_proxy ALL_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY SDKMACHINE BB_NUMBER_THREADS PARALLEL_MAKE GIT_PROXY_COMMAND GIT_PROXY_IGNORE SOCKS5_PASSWD SOCKS5_USER' +++ /home/lpapp/Projects/Yocto/poky-dylan-9.0.1/scripts/oe-setup-builddir You had no conf/local.conf file. This configuration file has therefore been created for you with some default values. You may wish to edit it to use a different MACHINE (target hardware) or enable parallel build options to take advantage of multiple cores for example. See the file for more information as common configuration options are commented. The Yocto Project has extensive documentation about OE including a reference manual which can be found at: http://yoctoproject.org/documentation For more information about OpenEmbedded see their website: http://www.openembedded.org/ You had no conf/bblayers.conf file. The configuration file has been created for you with some default values. To add additional metadata layers into your configuration please add entries to this file. The Yocto Project has extensive documentation about OE including a reference manual which can be found at: http://yoctoproject.org/documentation For more information about OpenEmbedded see their website: http://www.openembedded.org/ ### Shell environment set up for builds. ### You can now run 'bitbake target' Common targets are: core-image-minimal core-image-sato meta-toolchain meta-toolchain-sdk adt-installer meta-ide-support You can also run generated qemu images with a command like 'runqemu qemux86' +++ '[' -n /home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build ']' +++ cd /home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build +++ unset OEROOT +++ unset BBPATH ++ printf '\033_%s@%s:%s\033\' lpapp wheezy '~/Projects/Yocto/poky-dylan-9.0.1/build' ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] No versioning for existing images
On Mon, Feb 24, 2014 at 1:18 PM, Burton, Ross ross.bur...@intel.com wrote: On 24 February 2014 12:01, Laszlo Papp lp...@kde.org wrote: For instance, the MeeGo Nokia phone had a software version information in the settings, and that is something I would personally consider as the image version, but again, there might be better ways. Please share good practices in here., or alternatively, feel free to point me to any documentation, examples, etc. This is an interesting example and a useful demonstration of why the image version isn't always that useful. I am not sure about that; see below. The software build number covers *everything* that goes into the image, but the image version number is just the version of the top-level image recipe. The problem is that build numbers, that I have seen at least, are human unreadable. A human readable number would be nicer to have; something that I have just double checked on my Blackberry Limited Edition phone, and it is so that the OS Version is 10.0.10.738 in the settings. Perhaps the build number can be made human readable... but currently, when I build an image, all I get is a long and not so convenient time-stamp. Is there a more gentle way of generating image version then? If you bump the version of eglibc your image version won't be increased. Yes, but see above. There's nothing to stop you doing versioned images but as the version doesn't represent anything beyond the image recipe version it's not as useful as you'd think. Perhaps the image version is not the right way to address this issue; there might be other way, but it is still an important question for embedded system creators because I have seen that at several clients, and also on phones, that the software is shipped in one piece. I rarely see that individual packages are sent for a software upgrade. I rather see an incremental software update provided to the customers out there. The good example for this is the phones, tablets, etc (at least mine)... but there might be other examples, too. I would like to figure out a convenient and shared way or more of them how to deal with this generic issue. It is not vendor specific, I think. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Conf notes
On Mon, Feb 24, 2014 at 1:40 PM, Nicolas Dechesne nicolas.deche...@linaro.org wrote: On Mon, Feb 24, 2014 at 2:15 PM, Gary Thomas g...@mlbassoc.com wrote: I just tried this with the latest master and it is only looking in the meta-yocto layer even though there is a conf-notes.txt in one of my local layers as well. hmm. i just tried too. i create meta-layer with: $ find meta-mylayer/ meta-mylayer/ meta-mylayer/conf meta-mylayer/conf/conf-notes.txt meta-mylayer/conf/bblayers.conf.sample meta-mylayer/conf/layer.conf meta-mylayer/conf/local.conf.sample meta-mylayer/conf/site.conf.sample then, if I run $ TEMPLATECONF=meta-mylayer/conf . oe-init-build-env bbb It is working fine: ### Shell environment set up for builds. ### You can now run 'bitbake target' Common targets are: my-custom-image You can also run generated qemu images with a command like 'runqemu qemux86' I tried with up-to-date poky, e.g. commit a1faa7df2a0972fa631d3aee98c59f6b0e8eb43c Author: Richard Purdie richard.pur...@linuxfoundation.org Date: Mon Feb 24 12:57:38 2014 + It works with dylan, too? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] No versioning for existing images
On Mon, Feb 24, 2014 at 1:58 PM, Anders Darander and...@chargestorm.se wrote:
* Laszlo Papp lp...@kde.org [140224 14:37]:
On Mon, Feb 24, 2014 at 1:18 PM, Burton, Ross ross.bur...@intel.com wrote:
On 24 February 2014 12:01, Laszlo Papp lp...@kde.org wrote:
For instance, the MeeGo Nokia phone had a software version information
in the settings, and that is something I would personally consider as
the image version, but again, there might be better ways. Please share
good practices in here., or alternatively, feel free to point me to
any documentation, examples, etc.
This is an interesting example and a useful demonstration of why the
image version isn't always that useful.
I am not sure about that; see below.
The software build number
covers *everything* that goes into the image, but the image version
number is just the version of the top-level image recipe.
The problem is that build numbers, that I have seen at least, are
human unreadable. A human readable number would be nicer to have;
something that I have just double checked on my Blackberry Limited
Edition phone, and it is so that the OS Version is 10.0.10.738 in the
settings.
Perhaps the build number can be made human readable... but currently,
when I build an image, all I get is a long and not so convenient
time-stamp. Is there a more gentle way of generating image version
then?
Human readable... I think that I've got to agree with Ross on this one.
Though, the big question is about human readable...
For our internal images, we're using
IMAGE_PREPROCESS_COMMAND += rootfs_update_timestamp ;\
date +%Y%m%d%H%M ${IMAGE_ROOTFS}/etc/build ; \
git describe --dirty --long --always
${IMAGE_ROOTFS}/etc/version ;\
The first line is more or less the timestamp that you dislike.
The git describe line is our main versioning. Using that line we get the
abreviated SHA1 of our repo, the last tag, the number of commits after
the last tag, and finally whether the repo was clean or dirty during the
build.
This allows us internally to pinpoint the exact build setup (assuming
the build wasn't dirty, which it should never be on an autobuilder /
release build).
It might not be as pretty as the 10.0.10.738 in your example, though for
us it's sufficient for the time being.
As you are writing, that is good for internal operation, but I would
dislike providing such versioning for customers.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Conf notes
On Mon, Feb 24, 2014 at 2:13 PM, Nicolas Dechesne nicolas.deche...@linaro.org wrote: On Mon, Feb 24, 2014 at 3:09 PM, Laszlo Papp lp...@kde.org wrote: It works with dylan, too? yep. same output using: commit e2bb4a70a99a057d45316bbac65d6044ea54c484 Author: Chen Qi qi.c...@windriver.com Date: Sat Nov 16 03:19:55 2013 + subversion: fix build problem when sysroot contains '-D' or '-I' Right, we use 9.0.0, so it is not the same. This would be the same: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tag/?id=dylan-9.0.0 I have tried it now at least 5-10 times, including full build directory removal. It just does not work. Fwiw, we do not depend on the yocto layer at all; only core. Not sure if that matters. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] No versioning for existing images
On Mon, Feb 24, 2014 at 3:12 PM, Otavio Salvador ota...@ossystems.com.br wrote: Hello, On Mon, Feb 24, 2014 at 9:01 AM, Laszlo Papp lp...@kde.org wrote: I was wondering why existing images would not have version numbers attached. Say, we have a core-image-minimal image, but from the recipe, it is not possible which image version it is. Perhaps, it is just my ignorance and lack of understand, but for the moment, it seems to be an important information for e.g. distribution vendors and image creators to have an image version and the corresponding packages and versions attached to that particular version. It is easier to do a software upgrade then if you wish to do that based on the information of a certain image variant. I mean, it will lead to more manageable and reproducable images. It is possible that I am not aware of something important, so please enlighten me. It would be nice to see how other OE users do a system upgrade. For instance, the MeeGo Nokia phone had a software version information in the settings, and that is something I would personally consider as the image version, but again, there might be better ways. Please share good practices in here., or alternatively, feel free to point me to any documentation, examples, etc. You can have a product-version recipe which populates it based on the information you need (write it in a file in /etc and change PV as need). That way you can even track this using buildhistory. We do it for several products and it works quite well. All the need structure for it to work is avaiblue, just make the recipes in your product layer. Is your layer available in the open for further study? If not, can you give a minimal example? I personally feel separate recipe for a version number a bit too much for this. I would prefer a variable for it, like PRODUCT_VERSION or so. I think, that would be gratifying. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] No versioning for existing images
On Mon, Feb 24, 2014 at 2:51 PM, Anders Darander and...@chargestorm.se wrote: * Laszlo Papp lp...@kde.org [140224 15:12]: On Mon, Feb 24, 2014 at 1:58 PM, Anders Darander and...@chargestorm.se wrote: * Laszlo Papp lp...@kde.org [140224 14:37]: On Mon, Feb 24, 2014 at 1:18 PM, Burton, Ross ross.bur...@intel.com wrote: On 24 February 2014 12:01, Laszlo Papp lp...@kde.org wrote: The problem is that build numbers, that I have seen at least, are human unreadable. A human readable number would be nicer to have; something that I have just double checked on my Blackberry Limited Edition phone, and it is so that the OS Version is 10.0.10.738 in the settings. Perhaps the build number can be made human readable... but currently, when I build an image, all I get is a long and not so convenient time-stamp. Is there a more gentle way of generating image version then? The git describe line is our main versioning. Using that line we get the abreviated SHA1 of our repo, the last tag, the number of commits after the last tag, and finally whether the repo was clean or dirty during the build. It might not be as pretty as the 10.0.10.738 in your example, though for us it's sufficient for the time being. As you are writing, that is good for internal operation, but I would dislike providing such versioning for customers. Yes, for customer communication it might very well be preferred to use some other version numbers. I'd guess that the best bet then would be to either store the version number in a config file in your repo, and have the build process take that number and put it into the image in a way similar to what's above. Yes, I was thinking about a PRODUCT_VERSION or SOFTWARE_VERSION as a configuration option (and/or command line option). Or to get the number from a tag. Hmm, actually, this is not such bad an idea. In either case, you'll need to make sure that the release process updates the number correctly, thought that issue will be there no matter how you retreive and store the number. Yes, these things can be automated in release scripts, absolutely. Though, I still think that having the info above on the images are usefull, not least when the customer comes back with more difficult to isolate issues. I am not sure what information you mean. If you identify the image appropriately with a version and the corresponding list of package and versions (e.g. image BUILDHISTORY_FEATURE), I think you are good to go. Currently, I am not trying to solve such internal issues. It is more important for me at this stage to be able to provide a useful version to the end user and also for own sake, but admittedly, tag is actually a good idea, thanks. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] No versioning for existing images
On Mon, Feb 24, 2014 at 3:15 PM, Martin Jansa martin.ja...@gmail.com wrote: On Mon, Feb 24, 2014 at 03:51:19PM +0100, Anders Darander wrote: * Laszlo Papp lp...@kde.org [140224 15:12]: On Mon, Feb 24, 2014 at 1:58 PM, Anders Darander and...@chargestorm.se wrote: * Laszlo Papp lp...@kde.org [140224 14:37]: On Mon, Feb 24, 2014 at 1:18 PM, Burton, Ross ross.bur...@intel.com wrote: On 24 February 2014 12:01, Laszlo Papp lp...@kde.org wrote: The problem is that build numbers, that I have seen at least, are human unreadable. A human readable number would be nicer to have; something that I have just double checked on my Blackberry Limited Edition phone, and it is so that the OS Version is 10.0.10.738 in the settings. Perhaps the build number can be made human readable... but currently, when I build an image, all I get is a long and not so convenient time-stamp. Is there a more gentle way of generating image version then? The git describe line is our main versioning. Using that line we get the abreviated SHA1 of our repo, the last tag, the number of commits after the last tag, and finally whether the repo was clean or dirty during the build. It might not be as pretty as the 10.0.10.738 in your example, though for us it's sufficient for the time being. As you are writing, that is good for internal operation, but I would dislike providing such versioning for customers. Yes, for customer communication it might very well be preferred to use some other version numbers. I'd guess that the best bet then would be to either store the version number in a config file in your repo, and have the build process take that number and put it into the image in a way similar to what's above. Or to get the number from a tag. In either case, you'll need to make sure that the release process updates the number correctly, thought that issue will be there no matter how you retreive and store the number. Though, I still think that having the info above on the images are usefull, not least when the customer comes back with more difficult to isolate issues. in meta-webos we're appending human readable version suffix to IMAGE_NAME, KERNEL_IMAGE_BASE_NAME and MODULE_IMAGE_BASE_NAME variables and it's also included in some utils (like lsb and nyx-modules). That way we can distinguish not only what is in the image, but also where the image was built (e.g. official/local build, development/production version, which jenkins-job produced that etc). Right, this sounds well-organized and advanced. Currently, we do not need this much flexibility, but it is useful to know there are people doing it as professionally as you. :-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Conf notes
Hmm, I think something bizarre happened on my end. It seems that my file is lacking the `OECORENOTESCONF=$TEMPLATECONF/conf-notes.txt` line. That would explain all this, however this is present in dylan, even in 9.0.0. It seems to be that it was not present in denzil though. It is possible that some corruption occurred during the migration from denzil to dylan for us. I cannot possibly explain it for the moment because I just decompressed the poky tarball, and I think that was it. I mean, I would probably recall something silly, but not in this case... So, my memory is either very bad, or it is something else. I will let you know if I figure this out. Thank you for your time and patience. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Conf notes
Hi,
I have just put a conf notes file into my own layer, but when I source
the oe-init-build-env script, I am still getting the notes from Yocto
rather than my customized.
What am I doing wrong? I see this in the ./scripts/oe-setup-builddir file:
TEMPLATECONF=${TEMPLATECONF:-meta-yocto/conf}
and other references, but I have not pin the issue down just yet.
Cheers, L.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Removal of poky-feed-config-opkg_1.0.bb
Hi, I had a quick discussion on IRC with Ross. Is there a reason against removing it? ../meta/recipes-devtools/opkg/opkg-config-base_1.0.bb seems to be already doing the job. Is there any compatibility to be kept? Cheers, L. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] meta/recipes-core/base-passwd/base-passwd/noshadow.patch: Split it into two parts
Saul, would it be possible that you leave a short message on the
mailing list in the corresponding thread if a change is merged to
avoid such things in the future?
On Wed, Feb 5, 2014 at 3:49 PM, Saul Wold s...@linux.intel.com wrote:
On 02/05/2014 03:13 AM, Laszlo Papp wrote:
The current change contains two different logics resulting that users like
me
may need to partially override the behavior of it. It would be easier for
end
users to keep one change while dropping the other if needed, like in our
case.
I beleive that your first version of this was merged, is this different that
the one you send on 1/30?
It seems that the line count in this patch is different than the first,
please rebase against master and update this patch please.
Thanks
Sau!
Signed-off-by: Laszlo Papp lp...@kde.org
---
meta/recipes-core/base-passwd/base-passwd/nobash.patch | 10 +-
.../base-passwd/base-passwd/noshadow.patch | 18
++
meta/recipes-core/base-passwd/base-passwd_3.5.29.bb| 1 +
3 files changed, 20 insertions(+), 9 deletions(-)
create mode 100644
meta/recipes-core/base-passwd/base-passwd/noshadow.patch
diff --git a/meta/recipes-core/base-passwd/base-passwd/nobash.patch
b/meta/recipes-core/base-passwd/base-passwd/nobash.patch
index 6371576..eed87db 100644
--- a/meta/recipes-core/base-passwd/base-passwd/nobash.patch
+++ b/meta/recipes-core/base-passwd/base-passwd/nobash.patch
@@ -1,14 +1,6 @@
use /bin/sh instead of /bin/bash, since the latter may not be included
in
some images such as minimal
-comment added by Kevin Tian kevin.t...@intel.com, 2010-07-06
-
-remove * for root since we don't have a /etc/shadow so far.
-
-by Kevin Tian kevin.t...@intel.com, 2010-07-06
-
-Patch managed by http://www.mn-logistik.de/unsupported/pxa250/patcher
-
Upstream-Status: Invalid [configuration]
Signed-off-by: Scott Garman scott.a.gar...@intel.com
@@ -17,7 +9,7 @@ Signed-off-by: Scott Garman scott.a.gar...@intel.com
+++ base-passwd/passwd.master
@@ -1,4 +1,4 @@
-root:*:0:0:root:/root:/bin/bash
-+root::0:0:root:/root:/bin/sh
++root:*:0:0:root:/root:/bin/sh
daemon:*:1:1:daemon:/usr/sbin:/bin/sh
bin:*:2:2:bin:/bin:/bin/sh
sys:*:3:3:sys:/dev:/bin/sh
diff --git a/meta/recipes-core/base-passwd/base-passwd/noshadow.patch
b/meta/recipes-core/base-passwd/base-passwd/noshadow.patch
new file mode 100644
index 000..14e3959
--- /dev/null
+++ b/meta/recipes-core/base-passwd/base-passwd/noshadow.patch
@@ -0,0 +1,18 @@
+comment added by Kevin Tian kevin.t...@intel.com, 2010-07-06
+
+remove * for root since we don't have a /etc/shadow so far.
+
+by Kevin Tian kevin.t...@intel.com, 2010-07-06
+
+Upstream-Status: Invalid [configuration]
+
+Signed-off-by: Scott Garman scott.a.gar...@intel.com
+
+--- base-passwd/passwd.master~nobash
base-passwd/passwd.master
+@@ -1,4 +1,4 @@
+-root:*:0:0:root:/root:/bin/sh
++root::0:0:root:/root:/bin/sh
+ daemon:*:1:1:daemon:/usr/sbin:/bin/sh
+ bin:*:2:2:bin:/bin:/bin/sh
+ sys:*:3:3:sys:/dev:/bin/sh
diff --git a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
index 082037a..5b31fce 100644
--- a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
+++ b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
@@ -9,6 +9,7 @@ DEPENDS = docbook-utils-native linuxdoc-tools-native
SRC_URI = ${DEBIAN_MIRROR}/main/b/base-passwd/base-passwd_${PV}.tar.gz
\
file://add_shutdown.patch \
file://nobash.patch \
+ file://noshadow.patch \
file://input.patch \
file://disable-docs.patch \
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] meta/recipes-core/base-passwd/base-passwd/noshadow.patch: Split it into two parts
Why is it a nightmare? For instance, maintainers in other projects leave a Pushed, thanks note. See how much discussion this generates already, instead of two words. While you are at the change to merge it, you are already in place to leave the comment. However, contributors need to go and find the corresponding url, etc. Please note that contributors may want to know whether their voluntary work got merged without even a checkout, for instance double checking from mobile, etc. ... or is the real problem the lack of maintainer man power? On Sat, Feb 8, 2014 at 11:59 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Sat, 2014-02-08 at 11:50 +, Laszlo Papp wrote: Saul, would it be possible that you leave a short message on the mailing list in the corresponding thread if a change is merged to avoid such things in the future? We did used to do this but it turns out to be a nightmare for Saul and myself (the people who usually end up dealing with the patches) to do. Its relatively easily to update checkouts and note if a patch was merged. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Patch workflow [was: meta/recipes-core/base-passwd/base-passwd/noshadow.patch: Split it into two parts]
On Sat, Feb 8, 2014 at 12:20 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Sat, 2014-02-08 at 12:07 +, Laszlo Papp wrote: Why is it a nightmare? For instance, maintainers in other projects leave a Pushed, thanks note. See how much discussion this generates already, instead of two words. While you are at the change to merge it, you are already in place to leave the comment. However, contributors need to go and find the corresponding url, etc. Please note that contributors may want to know whether their voluntary work got merged without even a checkout, for instance double checking from mobile, etc. ... or is the real problem the lack of maintainer man power? Its both a man power problem and the process isn't as simple as described. The changes get batched together into large units, those get tested on the autobuilder. If they work out ok, the changes go in, if they fail, we pull out patches until we get a successful batch, then merge. Upon failures, we do aim to mention those on list. Having to go back through emails to find the ones which merge and ack them is a pain though since we are not already in place as you put it. Hmm, that is unfortunate, and practically speaking: having contributed to several projects, it is also a bit outstanding. It feels like the tools do not do the ideal job. There are only two people in general who do this on OE-Core, myself and Saul. We do have a ton of other pressures on our time, we do the best we can. If someone wants to ack patches that merge I'm happy for them to do so, it would be just as much work for them as it would for me/Saul. I am aware there are patch management tools out there which can show status of patches. We've looked hard at them and in general they impose more overhead and process onto people who don't want it. OK, can you please elaborate about the drawback of e.g. Gerrit? I was told before that it would not have the feature of off-line reading while flying on an airplane. Is this really such a common scenario for Yocto maintainers, or there are other reasons? I would imagine managers travel a lot more than maintainers. :-) Have you (Intel, Linux Foundation, etc) considered improving the existing tools? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Putting fltk into oe-core (recipes-graphics)
Hi Cristian, yes, you are right in my opinion; thank you for your follow up! The demo is very impressive, and as you say, native theme and look does not matter much on real embedded device, i.e. not generic computing mobile platforms - that are more powerful than some of the old, but still existing desktop machines - with its own UX design guide... Basically, the theme is what you define is, so I do not see issues in there. :-) In my experience, you would try hard to avoid X or even wayland on such devices in favor of framebuffer, etc. The problem, I see, I would need to grab a somewhat large oe layer to make a minimal UI on a real embedded device. That is not going to happen any soon. I would rather maintain my own fltk recipe in our layer instead. As for the touchscreen, yes, I would be actually interested in using fltk for touch screen devices. In fact, I already have some code, so I am just looking into the option to get the necessary libraries deployed by the Yocto project and openembedded-core. If you ask me, and I can throw my two cents in, qt and gtk are lotta more heavy and should not have made their way into oe-core IMHO, but perhaps it is only there for compatibility now. I mean, I would be fine with any good lightweight libraries on oe-core for creating minimal touch guis and that kind on minimal embedded devices, but I currently see no other option than writing your own ui kit with raw opengl, perhaps using glew from oe-core, etc. Suggestions would be welcome. I think oe-core could have this responsibility, but I will leave that with the maintainer... Cheers, L. On Tue, Feb 4, 2014 at 7:47 AM, Iorga, Cristian cristian.io...@intel.com wrote: Hi Laszlo, Maybe adding more information will make the case for it. For example, the fact that is used in a lot of OSS. A very good demo of the possibilities of FLTK is Giada, A Hardcore Loop Machine http://www.giadamusic.com/ In my opinion, it is one of the best looking apps written using FLTK for the graphical interface. Also, judging from the screenshots, I think it should be interesting to use it with a touch interface. However, I don't have any info regarding how well FLTK behaves in this aspect. Example screenshot: http://www.giadamusic.com/screenshot-09 Also, while Giada looks complex and with a lot of functionality built-in, the source code seems neat and tidy, which might be an argument regarding the fitness of FLTK in the embedded space. Giada's authors takes pride of the facts that the source code contains around 100 files and has around 30KLoC. Now, in my opinion, what is a little bit strange regarding FLTK is that it doesn't fit in, because it doesn't have a native look'n'feel on any of the supported platforms. But that's not really an issue in an embedded device, where FLTK might power up the only GUI needed for that particular device. Regards, Cristian Iorga YP Intel -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Laszlo Papp Sent: Monday, February 3, 2014 6:04 PM To: Richard Purdie Cc: openembedded-core Subject: Re: [OE-core] Putting fltk into oe-core (recipes-graphics) On Sat, Feb 1, 2014 at 9:02 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2014-01-30 at 18:46 +, Laszlo Papp wrote: Ping? I asked this a bit more than five months ago. Shall I take it as No? The lack of responses does indicate that its not something there is strong support for so I don't think fltk will be moving, correct. Currently, I do not see any minimal gui library in openembedded core for building some simple GUI on real embedded devices, but OK. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Putting fltk into oe-core (recipes-graphics)
On Sat, Feb 1, 2014 at 9:02 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2014-01-30 at 18:46 +, Laszlo Papp wrote: Ping? I asked this a bit more than five months ago. Shall I take it as No? The lack of responses does indicate that its not something there is strong support for so I don't think fltk will be moving, correct. Currently, I do not see any minimal gui library in openembedded core for building some simple GUI on real embedded devices, but OK. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] meta/recipes-core/base-passwd/base-passwd/noshadow.patch: Split it into two parts
The current change contains two different logics resulting that users like me
may need to partially override the behavior of it. It would be easier for end
users to keep one change while dropping the other if needed, like in our case.
Signed-off-by: Laszlo Papp lp...@kde.org
---
meta/recipes-core/base-passwd/base-passwd/nobash.patch | 10 +-
meta/recipes-core/base-passwd/base-passwd/noshadow.patch | 14 ++
meta/recipes-core/base-passwd/base-passwd_3.5.29.bb | 1 +
3 files changed, 16 insertions(+), 9 deletions(-)
create mode 100644 meta/recipes-core/base-passwd/base-passwd/noshadow.patch
diff --git a/meta/recipes-core/base-passwd/base-passwd/nobash.patch
b/meta/recipes-core/base-passwd/base-passwd/nobash.patch
index 6371576..eed87db 100644
--- a/meta/recipes-core/base-passwd/base-passwd/nobash.patch
+++ b/meta/recipes-core/base-passwd/base-passwd/nobash.patch
@@ -1,14 +1,6 @@
use /bin/sh instead of /bin/bash, since the latter may not be included in
some images such as minimal
-comment added by Kevin Tian kevin.t...@intel.com, 2010-07-06
-
-remove * for root since we don't have a /etc/shadow so far.
-
-by Kevin Tian kevin.t...@intel.com, 2010-07-06
-
-Patch managed by http://www.mn-logistik.de/unsupported/pxa250/patcher
-
Upstream-Status: Invalid [configuration]
Signed-off-by: Scott Garman scott.a.gar...@intel.com
@@ -17,7 +9,7 @@ Signed-off-by: Scott Garman scott.a.gar...@intel.com
+++ base-passwd/passwd.master
@@ -1,4 +1,4 @@
-root:*:0:0:root:/root:/bin/bash
-+root::0:0:root:/root:/bin/sh
++root:*:0:0:root:/root:/bin/sh
daemon:*:1:1:daemon:/usr/sbin:/bin/sh
bin:*:2:2:bin:/bin:/bin/sh
sys:*:3:3:sys:/dev:/bin/sh
diff --git a/meta/recipes-core/base-passwd/base-passwd/noshadow.patch
b/meta/recipes-core/base-passwd/base-passwd/noshadow.patch
new file mode 100644
index 000..e1cded6
--- /dev/null
+++ b/meta/recipes-core/base-passwd/base-passwd/noshadow.patch
@@ -0,0 +1,14 @@
+remove * for root since we don't have a /etc/shadow so far.
+
+Upstream-Status: Invalid [configuration]
+
+Signed-off-by: Scott Garman scott.a.gar...@intel.com
+
+--- base-passwd/passwd.master~nobash
base-passwd/passwd.master
+@@ -1,4 +1,4 @@
+-root:*:0:0:root:/root:/bin/sh
++root::0:0:root:/root:/bin/sh
+ daemon:*:1:1:daemon:/usr/sbin:/bin/sh
+ bin:*:2:2:bin:/bin:/bin/sh
+ sys:*:3:3:sys:/dev:/bin/sh
diff --git a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
index 082037a..5b31fce 100644
--- a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
+++ b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
@@ -9,6 +9,7 @@ DEPENDS = docbook-utils-native linuxdoc-tools-native
SRC_URI = ${DEBIAN_MIRROR}/main/b/base-passwd/base-passwd_${PV}.tar.gz \
file://add_shutdown.patch \
file://nobash.patch \
+ file://noshadow.patch \
file://input.patch \
file://disable-docs.patch \
--
1.8.5.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Putting fltk into oe-core (recipes-graphics)
Ping? I asked this a bit more than five months ago. Shall I take it as No? On Tue, Aug 27, 2013 at 7:59 AM, Laszlo Papp lp...@kde.org wrote: Hi all, was this thoroughly discussed before? I think the 'fltk' graphics library is quite lightweight. We still use that instead of qt and gtk on limited embedded platforms simply because it takes 1.2 MB or a bit more rather than a full blown Qt with 10-12+ MB. If I understand correctly there were discussions that gtk should not be inside openembedded core which I agree about. However, I think it would be useful to have some lightweight library like this in. Of course, this is lacking some features that Qt has, but that is why it is lightweight after all. :-) It is currently in the openembedded layer. It has a couple of minor dependencies which should probably be moved, but I do not see anything major. I think it is a more core option for ui building than the alternatives. This also supports opengl to a certain extent. Cheers, Laszlo ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ROOT_HOME: /home/root
Hi, Is there any obstacle why this cannot be /root as per default Unix philosophy [1]? It is not an unusual that the /home partition is a separate, and the sysadmins would like to manage the core system without getting that partition mounted, etc. It is true that it would be possible to work that around, but /root as a default just feels so much more natural on a Unix system. What I currently see after talking to a few people, the people keep changing it in their layer (distribution) config. It looks sub-optimal at first, but perhaps there are still valid reasons to keep this around? I was told on IRC the first embedded debian may have done it to keep rootfs read-only. First, you can remount the root partition on jffs2, ubifs, etc... as R/W. Even if you could not, you can have a separate /root partition which is a good idea anyway to keep the super-user separate from the regular users. If that is not OK, there is still the option for the minority to override it to /home/root if really needed, but I personally do not think it should be... So, all in all, I am in favor of changing this back to /root to be more linux-y and well-separated from the normal users. Unfortunately, it would lead to some breakages out there when they update Yocto, so it may not be acceptable in this project. I do not know the rules. The migration could be aided though with some proper documentation. Cheers, L. [1] FHS 2.3 still says /root : Home directory for the root user (optional) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ROOT_HOME: /home/root
On Wed, Jan 29, 2014 at 12:37 PM, Phil Blundell p...@pbcl.net wrote: On Wed, 2014-01-29 at 12:32 +, Laszlo Papp wrote: Is there any obstacle why this cannot be /root as per default Unix philosophy [1]? No. This is distro policy and you (or your DISTRO) can set it to anything you like. The email is not about distributions, but the default value in Yocto (the distribution generator itself) ... ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ROOT_HOME: /home/root
On Wed, Jan 29, 2014 at 12:52 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2014-01-29 at 12:32 +, Laszlo Papp wrote: Hi, Is there any obstacle why this cannot be /root as per default Unix philosophy [1]? It is not an unusual that the /home partition is a separate, and the sysadmins would like to manage the core system without getting that partition mounted, etc. It is true that it would be possible to work that around, but /root as a default just feels so much more natural on a Unix system. What I currently see after talking to a few people, the people keep changing it in their layer (distribution) config. It looks sub-optimal at first, but perhaps there are still valid reasons to keep this around? I was told on IRC the first embedded debian may have done it to keep rootfs read-only. First, you can remount the root partition on jffs2, ubifs, etc... as R/W. Even if you could not, you can have a separate /root partition which is a good idea anyway to keep the super-user separate from the regular users. If that is not OK, there is still the option for the minority to override it to /home/root if really needed, but I personally do not think it should be... So, all in all, I am in favor of changing this back to /root to be more linux-y and well-separated from the normal users. Unfortunately, it would lead to some breakages out there when they update Yocto, so it may not be acceptable in this project. I do not know the rules. The migration could be aided though with some proper documentation. These directories can be configured by the user extremely easily. To be fair, it would be just as extremely easy to configure it to /home/root as the other way around. By having a default of /home/root/ we can catch software that has issues with relocation of that. I am not sure what you mean. Could you please elaborate? Having the writeable user data in one directory like this is useful for several classes of embedded style devices. Could you please provide any examples? I have not seen any use cases myself out there, but after a quick poke around, other people seem to have similar experiences around me. As written in my initial email, I do not target several use cases. I am referring to the majority which, as per Unix philosophy, I am somewhat opinionated that is /root. So to be honest I don't see a pressing reason to change this. I do, because the earlier it is done, the fewer users that may have incompatible changes. As the time goes ahead, more and more users will stick to it as default. I believe this means those who do not care about proper Unix separation. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ROOT_HOME: /home/root
On Wed, Jan 29, 2014 at 1:13 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2014-01-29 at 12:59 +, Laszlo Papp wrote: On Wed, Jan 29, 2014 at 12:52 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2014-01-29 at 12:32 +, Laszlo Papp wrote: By having a default of /home/root/ we can catch software that has issues with relocation of that. I am not sure what you mean. Could you please elaborate? As you mention, /root is more standard. It therefore becomes hard to spot software that assumes this rather than using the directory we configure it to if the default is also /root. By having a slightly more unusual default choice, we quickly find the software that doesn't adapt to our variable. You seem to be referring to testing rather than forcing a test case for the software, and hence majority. There are two better alternatives IMHO to address this: a) QA team defines such a test case. b) In addition to a), you would get reports from users who set it to /home/root if there are issues. Although, I am certainly questioning that if more than 10-20% was setting it to /home/root at all, or even much less. Daniel in the CC also wrote an issue on IRC that it could lead to a non-loginable system if the /home does not get mounted which would better not be mandatory without setting it explicitly IMHO. Having the writeable user data in one directory like this is useful for several classes of embedded style devices. Could you please provide any examples? One that springs to mind is the Sharp Zaurus series of PDAs have separate /home partitions in flash. You can reflash a new rootfs without overwriting the user config data. I addressed this issue in my initial email, but I will reiterate this concern with two solutions: a) You can do package update rather than reflashing. b) Even if a) does not work, as written in my initial email, you can have a /root partition. Still, the fact that you can only mention one use here, is somewhat also self-explanatory that it is not the majority. So to be honest I don't see a pressing reason to change this. I do, because the earlier it is done, the fewer users that may have incompatible changes. As the time goes ahead, more and more users will stick to it as default. I believe this means those who do not care about proper Unix separation. Its been like this for years and seems to work perfectly fine for people. I do not see it perfectly fine that if the majority of the people get the extra work rather than the minority. I saw this several times now in the history that it was done manually on the end-users side, and since it is not just me, I thought I would bring this topic up. I would rather prefer to ease the end users' work wherever it is possible. You can configure it just fine. As I said previously, I see no pressing reason to change it. As written before, you could configure the other way around, too. The question boils down to that: who should configure it on its own? * The person who tries to follow the unix philosophy and the generic behavior on most of the Unix systems out there? * The person who follows some rare use case? My opinion is the former. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ROOT_HOME: /home/root
On Wed, Jan 29, 2014 at 2:06 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 29 jan. 2014, om 13:39 heeft Laszlo Papp lp...@kde.org het volgende geschreven: On Wed, Jan 29, 2014 at 12:37 PM, Phil Blundell p...@pbcl.net wrote: On Wed, 2014-01-29 at 12:32 +, Laszlo Papp wrote: Is there any obstacle why this cannot be /root as per default Unix philosophy [1]? No. This is distro policy and you (or your DISTRO) can set it to anything you like. The email is not about distributions, but the default value in Yocto (the distribution generator itself) ... You mean OE, right? Yocto is 10^-something, the Yocto *Project* is an umbrella project contain lots of things, among which is OE, which can build a distro for you. No, I mean Yocto. I am not directly concerned about OE as I am not a direct user. I would like to fix this in Yocto itself. It is fine if it is fixed in OE proper or worked around in Yocto. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ROOT_HOME: /home/root
On Wed, Jan 29, 2014 at 3:16 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 29 jan. 2014, om 16:04 heeft Laszlo Papp lp...@kde.org het volgende geschreven: On Wed, Jan 29, 2014 at 2:06 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 29 jan. 2014, om 13:39 heeft Laszlo Papp lp...@kde.org het volgende geschreven: On Wed, Jan 29, 2014 at 12:37 PM, Phil Blundell p...@pbcl.net wrote: On Wed, 2014-01-29 at 12:32 +, Laszlo Papp wrote: Is there any obstacle why this cannot be /root as per default Unix philosophy [1]? No. This is distro policy and you (or your DISTRO) can set it to anything you like. The email is not about distributions, but the default value in Yocto (the distribution generator itself) ... You mean OE, right? Yocto is 10^-something, the Yocto *Project* is an umbrella project contain lots of things, among which is OE, which can build a distro for you. No, I mean Yocto. So 10^-24. I have no idea how to convince the SI that 10^24 needs a home directory switch. I am not sure what you mean, really, but either way: I would prefer getting back on track. I am not directly concerned about OE as I am not a direct user. I would like to fix this in Yocto itself. It is fine if it is fixed in OE proper or worked around in Yocto. Inconceivable! I think you are confusing 'Yocto Project' and 'Poky' here. I Please read up on what words mean before using them. ... or just listen to the user what he is writing... :-) I am a user of Yocto project. I am reporting issues against Yocto, on the Yocto issue tracker, etc. Fwiw, I am not even planning to use the Poky distribution... Either way, I do not wish to continue arguing over these words because it is not that useful for anyone IMHO. I would prefer more input about the actual proposal. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] local.conf.sample: Add automatic defaults for BB_NUMBER_THREADS and PARALLEL_MAKE
Thank you for this contribution.
As a side note, please consider the documentation bits in the future
as well. :-) I have just opened a separate ticket for that here:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5770
On Mon, Jan 27, 2014 at 2:39 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
Its rather sad that people don't appear to read local.conf and then complain
about slow builds when they're just using a single thread. Most systems have
more than one core now so we might as well use a more automatic default
for these values. This may lead to better experiences for new users.
[YOCTO #2528]
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/conf/local.conf.sample b/meta/conf/local.conf.sample
index 71856b8..36d33e1 100644
--- a/meta/conf/local.conf.sample
+++ b/meta/conf/local.conf.sample
@@ -18,12 +18,18 @@
# option determines how many tasks bitbake should run in parallel:
#
#BB_NUMBER_THREADS ?= 4
+#
+# Default to setting automatically based on cpu count
+BB_NUMBER_THREADS ?= ${@oe.utils.cpu_count()}
#
# The second option controls how many processes make should run in parallel
when
# running compile tasks:
#
#PARALLEL_MAKE ?= -j 4
#
+# Default to setting automatically based on cpu count
+PARALLEL_MAKE ?= -j ${@oe.utils.cpu_count()}
+#
# For a quad-core machine, BB_NUMBER_THREADS = 4, PARALLEL_MAKE = -j 4
would
# be appropriate for example.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lib/oe/patch.py: Prefer git am over git apply when applying git patches
Hi everyone, the patch was sent about three weeks ago, and I have not seen any objections so far. What is the issue for progressing? Please let me know. Cheers, L. On Thu, Jan 9, 2014 at 4:53 PM, Laszlo Papp lp...@kde.org wrote: On Tue, Jan 7, 2014 at 12:16 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 6 jan. 2014, om 23:10 heeft Saul Wold s...@linux.intel.com het volgende geschreven: On 12/31/2013 06:18 AM, Laszlo Papp wrote: Ping? Alternatively, the system could also have an option for further fine-tuning what to do with git patches On Tue, Dec 24, 2013 at 12:44 PM, Laszlo Papp lp...@kde.org wrote: It is better to use git am when possible to preserve the commit messages and the mail format in general for patches when those are present. A typical use case is when developers would like to keep the changes on top of the latest upstream, and they may occasionally need to rebase. This is not possible with git diff and diff generated patches. Since this is not always the case, the fallback would be the git apply operation which is currently available. Looking at this, is it possible to detect a git patch and only then use git am? Since most of the patches carried in oe-core and other layers the 'git am' will typically fail All the patches I add are git am'able since I use a patch similar to this :) Cool. A big timesaver is to check for a .git/ in $WORKDIR otherwise git am will try to use a top level git tree (e.g. combo repo) and that's not what we want. Hmm, yeah, I agree. However, I do not have time currently for this, nor is this high-priority for me since it just works for me, and I am happy with that. Would it be possible to optimize it later? Failing that, what is the best practice to keep my changes separate from Yocto? I am referring to changes that are not upstreamed for whatever reason, like the maintainer saying that here it could be a performance regression (although non-measured at this point). Cheers ... ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lib/oe/patch.py: Prefer git am over git apply when applying git patches
On Tue, Jan 7, 2014 at 11:46 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Mon, Jan 6, 2014 at 8:10 PM, Saul Wold s...@linux.intel.com wrote: On 12/31/2013 06:18 AM, Laszlo Papp wrote: Ping? Alternatively, the system could also have an option for further fine-tuning what to do with git patches On Tue, Dec 24, 2013 at 12:44 PM, Laszlo Papp lp...@kde.org wrote: It is better to use git am when possible to preserve the commit messages and the mail format in general for patches when those are present. A typical use case is when developers would like to keep the changes on top of the latest upstream, and they may occasionally need to rebase. This is not possible with git diff and diff generated patches. Since this is not always the case, the fallback would be the git apply operation which is currently available. Looking at this, is it possible to detect a git patch and only then use git am? Since most of the patches carried in oe-core and other layers the 'git am' will typically fail and increase the build time since it will have to re-run the git apply, we don't want to had more forking and work in the main hot path. I am not the expert in this, neither is RP, so maybe Chris can comment further. I am not sure it'd buy us a lot trying to detect it; in fact using git am patches easy rework, rebase and upstreaming of those. +1 To detect it, we'd need to parse the file somehow and I am unsure it would be faster than just try to apply it. Agree; it may even be slower. I think it could be separated out later into a custom option if any performance issue comes up. IMO, it is a reasonable assumption if the patchtool set is git, then it is a git patch, not raw diff... ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lib/oe/patch.py: Prefer git am over git apply when applying git patches
On Tue, Jan 7, 2014 at 12:16 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 6 jan. 2014, om 23:10 heeft Saul Wold s...@linux.intel.com het volgende geschreven: On 12/31/2013 06:18 AM, Laszlo Papp wrote: Ping? Alternatively, the system could also have an option for further fine-tuning what to do with git patches On Tue, Dec 24, 2013 at 12:44 PM, Laszlo Papp lp...@kde.org wrote: It is better to use git am when possible to preserve the commit messages and the mail format in general for patches when those are present. A typical use case is when developers would like to keep the changes on top of the latest upstream, and they may occasionally need to rebase. This is not possible with git diff and diff generated patches. Since this is not always the case, the fallback would be the git apply operation which is currently available. Looking at this, is it possible to detect a git patch and only then use git am? Since most of the patches carried in oe-core and other layers the 'git am' will typically fail All the patches I add are git am'able since I use a patch similar to this :) Cool. A big timesaver is to check for a .git/ in $WORKDIR otherwise git am will try to use a top level git tree (e.g. combo repo) and that's not what we want. Hmm, yeah, I agree. However, I do not have time currently for this, nor is this high-priority for me since it just works for me, and I am happy with that. Would it be possible to optimize it later? Failing that, what is the best practice to keep my changes separate from Yocto? I am referring to changes that are not upstreamed for whatever reason, like the maintainer saying that here it could be a performance regression (although non-measured at this point). Cheers ... ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lib/oe/patch.py: Prefer git am over git apply when applying git patches
Ping?
Alternatively, the system could also have an option for further
fine-tuning what to do with git patches
On Tue, Dec 24, 2013 at 12:44 PM, Laszlo Papp lp...@kde.org wrote:
It is better to use git am when possible to preserve the commit messages and
the mail format in general for patches when those are present. A typical use
case is when developers would like to keep the changes on top of the latest
upstream, and they may occasionally need to rebase. This is not possible with
git diff and diff generated patches.
Since this is not always the case, the fallback would be the git apply
operation which is currently available.
Signed-off-by: Laszlo Papp lp...@kde.org
---
meta/lib/oe/patch.py | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index 59abd0a..b085c9d 100644
--- a/meta/lib/oe/patch.py
+++ b/meta/lib/oe/patch.py
@@ -203,17 +203,23 @@ class GitApplyTree(PatchTree):
PatchTree.__init__(self, dir, d)
def _applypatch(self, patch, force = False, reverse = False, run = True):
-shellcmd = [git, --git-dir=., apply, -p%s %
patch['strippath']]
+def _applypatchhelper(shellcmd, patch, force = False, reverse =
False, run = True):
+if reverse:
+shellcmd.append('-R')
-if reverse:
-shellcmd.append('-R')
+shellcmd.append(patch['file'])
-shellcmd.append(patch['file'])
+if not run:
+return sh + -c + .join(shellcmd)
-if not run:
-return sh + -c + .join(shellcmd)
+return runcmd([sh, -c, .join(shellcmd)], self.dir)
-return runcmd([sh, -c, .join(shellcmd)], self.dir)
+try:
+shellcmd = [git, --work-tree=., am, -3, -p%s %
patch['strippath']]
+return _applypatchhelper(shellcmd, patch, force, reverse, run)
+except CmdError:
+shellcmd = [git, --git-dir=., apply, -p%s %
patch['strippath']]
+return _applypatchhelper(shellcmd, patch, force, reverse, run)
class QuiltTree(PatchSet):
--
1.8.5.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] lib/oe/patch.py: Prefer git am over git apply when applying git patches
It is better to use git am when possible to preserve the commit messages and
the mail format in general for patches when those are present. A typical use
case is when developers would like to keep the changes on top of the latest
upstream, and they may occasionally need to rebase. This is not possible with
git diff and diff generated patches.
Since this is not always the case, the fallback would be the git apply
operation which is currently available.
Signed-off-by: Laszlo Papp lp...@kde.org
---
meta/lib/oe/patch.py | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index 59abd0a..b085c9d 100644
--- a/meta/lib/oe/patch.py
+++ b/meta/lib/oe/patch.py
@@ -203,17 +203,23 @@ class GitApplyTree(PatchTree):
PatchTree.__init__(self, dir, d)
def _applypatch(self, patch, force = False, reverse = False, run = True):
-shellcmd = [git, --git-dir=., apply, -p%s % patch['strippath']]
+def _applypatchhelper(shellcmd, patch, force = False, reverse = False,
run = True):
+if reverse:
+shellcmd.append('-R')
-if reverse:
-shellcmd.append('-R')
+shellcmd.append(patch['file'])
-shellcmd.append(patch['file'])
+if not run:
+return sh + -c + .join(shellcmd)
-if not run:
-return sh + -c + .join(shellcmd)
+return runcmd([sh, -c, .join(shellcmd)], self.dir)
-return runcmd([sh, -c, .join(shellcmd)], self.dir)
+try:
+shellcmd = [git, --work-tree=., am, -3, -p%s %
patch['strippath']]
+return _applypatchhelper(shellcmd, patch, force, reverse, run)
+except CmdError:
+shellcmd = [git, --git-dir=., apply, -p%s %
patch['strippath']]
+return _applypatchhelper(shellcmd, patch, force, reverse, run)
class QuiltTree(PatchSet):
--
1.8.5.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Bug: 5089
Hi, there was this change which also goes undocumented. Unfortunately, this is causing a lot of headache for me, but I expect that for others, too. I would like to propose the default kernel and module name from: uImage--3.2.1... to: uImage-3.2.1... This would avoid a lot of work for people. I have been trying to fix issues for one day due to this which is unfortunate. Also, the double dash on its looks silly IMO. It should be either '-0-' or '-'. I prefer the latter for compatibility reasons, although someone could argue about that the former is more readable. I heard Jama's opinion about it on IRC. I wonder what others think? Cheers, Laszlo PS.: Note, this is a different proposal to the documentation update. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Bug: 5089
On Fri, Aug 30, 2013 at 1:47 PM, Bruce Ashfield bruce.ashfi...@gmail.comwrote: On Fri, Aug 30, 2013 at 7:45 AM, Laszlo Papp lp...@kde.org wrote: Hi, there was this change which also goes undocumented. Unfortunately, this is causing a lot of headache for me, but I expect that for others, too. I would like to propose the default kernel and module name from: uImage--3.2.1... to: uImage-3.2.1... This would avoid a lot of work for people. I have been trying to fix issues for one day due to this which is unfortunate. Also, the double dash on its looks silly IMO. It should be either '-0-' or '-'. I prefer the latter for compatibility reasons, although someone could argue about that the former is more readable. Having maintained several systems when the default name was changed to include PE, it didn't cause any problems here. Both dependent recipes and scripts picked up the change easily and convenience symlinks made the -- or -0- not something that needed to be dealt with. That makes me think you have too flexible scripts which will cause issues elsewhere due to the flexibility. I had been on that front, too. That was a gate in my case for a lot of issues where something was expected, but the script was too flexible to verify properly. Either, when you use an accurate script, i.e. you follow the name format specified, it will cause you issues when updated. It is likely that you just have not provided accurate enough pattern matching. Anyway, I will not insist on this much if people think breaking this for many scripts is fine, and extending the documentation should be enough. -- Laszlo ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Why is bitbake core-image-minimal building gtk docs?
OK, it seems to finally work on our CI. Thanks to all for the help. On Thu, Aug 29, 2013 at 6:15 PM, Laszlo Papp lp...@kde.org wrote: On Thu, Aug 29, 2013 at 5:19 PM, Laszlo Papp lp...@kde.org wrote: On Wed, Aug 21, 2013 at 3:59 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: Regardless of whether you use mirrors or not, if you set BB_GENERATE_MIRROR_TARBALLS it will create tarballs in DL_DIR of the git repositories. You can then stop trying to check in the /git/ and /git2/ subdirectories of DL_DIR and some of your problems will likely go away. Actually, I have just spent one hour with a full rebuild, but putting this variable into the local.conf did not generate any different downloads folder. Any other idea how to get rid of the git hassle in here without a major infrastructure refactor? What I executed was: git rm -r ./downloads/git2 git commit ./downloads/git2. Even after that, it is broken. :( ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Why is bitbake core-image-minimal building gtk docs?
On Wed, Aug 21, 2013 at 12:04 PM, Martin Jansa martin.ja...@gmail.comwrote:
It does, all you need to do is enable BB_GENERATE_MIRROR_TARBALLS
I need all the three lines or just the last?
SOURCE_MIRROR_URL ?= file://${DL_DIR}
INHERIT += own-mirrors
BB_GENERATE_MIRROR_TARBALLS = 1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Why is bitbake core-image-minimal building gtk docs?
On Wed, Aug 21, 2013 at 3:59 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: Regardless of whether you use mirrors or not, if you set BB_GENERATE_MIRROR_TARBALLS it will create tarballs in DL_DIR of the git repositories. You can then stop trying to check in the /git/ and /git2/ subdirectories of DL_DIR and some of your problems will likely go away. Actually, I have just spent one hour with a full rebuild, but putting this variable into the local.conf did not generate any different downloads folder. Any other idea how to get rid of the git hassle in here without a major infrastructure refactor? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Why is bitbake core-image-minimal building gtk docs?
On Thu, Aug 29, 2013 at 5:19 PM, Laszlo Papp lp...@kde.org wrote: On Wed, Aug 21, 2013 at 3:59 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: Regardless of whether you use mirrors or not, if you set BB_GENERATE_MIRROR_TARBALLS it will create tarballs in DL_DIR of the git repositories. You can then stop trying to check in the /git/ and /git2/ subdirectories of DL_DIR and some of your problems will likely go away. Actually, I have just spent one hour with a full rebuild, but putting this variable into the local.conf did not generate any different downloads folder. Any other idea how to get rid of the git hassle in here without a major infrastructure refactor? What I executed was: git rm -r ./downloads/git2 git commit ./downloads/git2. Even after that, it is broken. :( ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Putting fltk into oe-core (recipes-graphics)
Hi all, was this thoroughly discussed before? I think the 'fltk' graphics library is quite lightweight. We still use that instead of qt and gtk on limited embedded platforms simply because it takes 1.2 MB or a bit more rather than a full blown Qt with 10-12+ MB. If I understand correctly there were discussions that gtk should not be inside openembedded core which I agree about. However, I think it would be useful to have some lightweight library like this in. Of course, this is lacking some features that Qt has, but that is why it is lightweight after all. :-) It is currently in the openembedded layer. It has a couple of minor dependencies which should probably be moved, but I do not see anything major. I think it is a more core option for ui building than the alternatives. This also supports opengl to a certain extent. Cheers, Laszlo ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot: update to 2013.07
On Mon, Aug 26, 2013 at 6:55 PM, Saul Wold s...@linux.intel.com wrote: Thanks for the contribution. Looks my first contribution which is in then! Yay, thanks. :) -- Laszlo ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot: update to 2013.07
On Tue, Aug 27, 2013 at 8:57 PM, Randy MacLeod randy.macl...@windriver.comwrote: Am I missing something or are people just copying and pasting the text? I was just copying and pasting it. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot: update to 2013.07
On Mon, Aug 26, 2013 at 7:04 PM, Saul Wold s...@linux.intel.com wrote: On 08/26/2013 10:56 AM, Laszlo Papp wrote: What exactly is the problem for beagle board? The QA team did not provide the details. I wonder if you could ask for that? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot: update to 2013.07
This email contains some nuances, so I will try to reply to the main points (IMO). On Mon, Aug 26, 2013 at 10:48 PM, Peter A. Bigot p...@pabigot.com wrote: Is there reason to create a parallel UBOOT_VERSION? Yes. fw-utils is not available with this u-boot version just yet. Also, I have not tested all the reference BSPs. Is there a better approach than bbappend-in-layer that I should use for adding patches required for a specific u-boot machine? That is hard to answer without details. fw-utils could be some help layer, maybe. Other than that, what do you mean? Something like config fragments (see busybox)? Cheers, Laszlo ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
