Re: [yocto] default root password
Hi Bryan,
Solved this using the ROOTFS_POSTPROCESS_COMMAND, but without the
patches series for > 8 characters password. Thanks for that input :-)
Using danny in this particular case.
Hope someone will update the FAQ !
Thanks
David
-Original Message-
From: Bryan Evenson [mailto:beven...@melinkcorp.com]
Sent: jeudi 17 octobre 2013 15:23
To: David Andrey; yocto@yoctoproject.org
Subject: RE: default root password
David,
I've had similar issues, and this is what I've done to get the root
password set properly in my image. I am using poky/Dylan-9.0.1 for a
starting point.
1. In my case, I want a root password that is longer than 8 characters.
With poky/dylan, it is using tinylogin for password management which has
an issue with passwords longer than 8 characters; it looks like it is
using them, but it only pays attention to the first 8 characters. If
you want to use a root password that is longer than 8 characters, there
is a 10 patch series under poky/master submitted by Chen Qi on
2013-06-25. Cherry-pick these 10 patches and apply them to your local
poky repository. Rebuild your image with "debug-tweaks" set in
local.conf.
2. Boot up your newly built image with the default blank password (or
some other password you know what it is). Then, change the root
password using the passwd command. If you want a root password that is
longer than 8 characters, use "passwd -m".
3. Look at the contents of /etc/shadow. Everything between the first
two colons on root's line is its password. For example, if it looked
like this:
root:$QAGQ$%Y#QTRAG%^J#$#QR$@:15924:0:9:7:::
then $QAGQ$%Y#QTRAG%^J#$#QR$@ would be root's encrypted password. Copy
that text.
4. Add the following to the end of your image recipe:
ROOTFS_POSTPROCESS_COMMAND += "\
sed 's%^root:[^:]*:%root::%' \
< ${IMAGE_ROOTFS}/etc/shadow \
> ${IMAGE_ROOTFS}/etc/shadow.new;\
mv ${IMAGE_ROOTFS}/etc/shadow.new ${IMAGE_ROOTFS}/etc/shadow ;"
and that will change root's password in your image.
I know there is the EXTRA_USER_PARAMS feature for adding users and
modifying a user's password, but I couldn't get it to work for root. I
tried adding:
INHERIT += "extrausers"
EXTRA_USERS_PARAMS = "\
usermod -p '' root; \
"
and I would get errors when building the image. I can't remember the
errors I got, but I couldn't get the build to complete when I tried to
modify the root password in this manner. The other way worked so I went
with that.
Hope that helps.
-Bryan Evenson
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of David Andrey
> Sent: Wednesday, October 16, 2013 8:58 AM
> To: yocto@yoctoproject.org
> Subject: [yocto] default root password
>
> Hi,
>
> There are lot of threads floating around, and a FAQ without answer.
> https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_set_or_change_the_root
> _
> p
> assword
>
> So what is the official way to set a default root password ?
> Using a sed command on /etc/passwd through ROOTFS_POSTPROCESS_COMMAND
> or is there any other built-in solution ?
>
> regards
> David
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to enable LTP support in "core-image-basic"
Hi, I wants to use the LTP test suite provided by yocto project. But I don't know how to enable it for "core-image-basic". Can anyone help me to enable the LTP in "core-image-basic"? Thanks & Regards Amit K The contents of this e-mail and any attachment(s) may contain confidential or privileged information for the intended recipient(s). Unintended recipients are prohibited from taking action on the basis of information in this e-mail and using or disseminating the information, and must notify the sender and delete it from their system. L&T Infotech will not accept responsibility or liability for the accuracy or completeness of, or the presence of any virus or disabling code in this e-mail" ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom defconfig is not used
2013/10/18 Bruce Ashfield
> I fell behind today .. i had 2300 unread email to start this morning :)
> Is there a way that I can get a copy of your recipes and layers ? If
> I can do a build myself, I can easily debug and fix this .. otherwise,
> we'll
> go back and forth many times debugging.
>
> Cheers,
>
> Bruce
>
I'm using the environment provided by Angstrom from it's github setup
scripts.
If you want to exactly reproduce it you need to:
git clone https://github.com/Angstrom-distribution/setup-scripts.git
cd setup-scripts
git checkout angstrom-v2013.06-yocto1.4
MACHINE=beaglebone ./oebb.sh config beaglebone
Here is the setup and files for meta-mine:
bblayers.conf:
BBLAYERS = \"
...
${TOPDIR}/sources/meta-mine \
"
meta-mine/conf/layer.conf:
# We have a conf and classes directory, append to BBPATH
BBPATH .= ":${LAYERDIR}"
# We have a recipes directory, add to BBFILES
BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend"
BBFILE_COLLECTIONS += "mine-layer"
BBFILE_PATTERN_mine-layer := "^${LAYERDIR}/"
BBFILE_PRIORITY_mine-layer = "10"
LAYERDEPENDS_mine-layer = "angstrom-layer"
meta-mine/recipes-kernel/linux/linux-mainline_3.8.bbappend:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
SRC_URI += " file://config-addons.cfg "
meta-mine/recipes-kernel/linux/linux-mainline-3.8/config-addons.cfg:
CONFIG_WATCHDOG_NOWAYOUT=y
CONFIG_NTFS_FS=y
CONFIG_NTFS_RW=y
But I think that instead of using the whole Angstrom you can just use poky
and meta-beagleboard/common-bsp on dylan branch.
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to enable LTP support in "core-image-basic"
Adding IMAGE_FEATURES += "splash ssh-server-openssh ltp" in core-image-basic.bb will enable ltp in your final image. Make sure you have added all required layers :) //Gaurang Shastri On Fri, Oct 18, 2013 at 12:47 PM, Amit Kumar wrote: > Hi, > >I wants to use the LTP test suite provided by yocto project. > But I don’t know how to enable it for “core-image-basic”. > > Can anyone help me to enable the LTP in “core-image-basic”? > > ** ** > > ** ** > > Thanks & Regards > > Amit K > > -- > The contents of this e-mail and any attachment(s) may contain confidential > or privileged information for the intended recipient(s). Unintended > recipients are prohibited from taking action on the basis of information in > this e-mail and using or disseminating the information, and must notify the > sender and delete it from their system. L&T Infotech will not accept > responsibility or liability for the accuracy or completeness of, or the > presence of any virus or disabling code in this e-mail" > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to enable LTP support in "core-image-basic"
On Friday 18 October 2013 14:50:51 Gaurang Shastri wrote: > Adding > > IMAGE_FEATURES += "splash ssh-server-openssh ltp" in core-image-basic.bb > > will enable ltp in your final image. Make sure you have added all > required layers :) Ah, that doesn't look right - I don't think we have an "ltp" IMAGE_FEATURES item. Adding "tools-testapps" will bring in ltp as well as some other testing tools, otherwise you can just add "ltp" to IMAGE_INSTALL within the image recipe or alternatively you can use other means to add the package as described in the manual: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] OPKG configuration questions
> > On 17 October 2013 11:20, Glenn Schmottlach wrote: >> > Just out of curiosity, is it possible that you added "package-management" >> > to IMAGE_FEATURES after you already had a successful full build? Or is >> > it possible that you had already done a full build with "package_rpm" or >> > "_deb" before switching to "package_ipk"? >> > >> >> I added "package-management" after a successful build. > > In that case, if you have the time, I would delete your tmp, > sstate-cache, and cache directories, as well as your bitbake.lock and > pseudodone files and rebuild. Does that make any difference? > Unbeknownst to me, the "init" script on the target platform was mounting a tmpfs (ramdisk) filesystem over the top of "/var" thereby hiding the fact that the opkg database had indeed been installed. So, once I realized this it was clear why I wasn't see these files when the target booted. >> > The reason I ask is (although I never confirmed this definitively but) when >> > I was playing with this stuff a while back I was sure that this package >> > stuff >> > would only get generated after adjusting these configurations when a full, >> > clean build was performed (i.e. removing and ). > >> After manually copying the /var/lib/opkg to my target the opkg-cl >> command now seems to "work". Unfortunately I'm running into difficulty >> specifying a a new ipkg repo that is mounted via NFS from my >> development machine. How would I make it scan there as well? > > I've never tried that before. But maybe if you created a file (on the > target) called, for example, /etc/opkg/nfs.conf which contained: > > src/gz nfs /path/to/nfs > > maybe that would work? Don't forget to perform an "# opkg update" > after creating that file. > After some trial-and-error (and remembering to call opkg-cl update as you suggested) I was able to get my alternative feed to work. So at this point, I *think* I have it all figured out ;-) Thanks to those on the list who offered their suggestions! > There's also a remote chance adding this new repository doesn't appear > to work because your target filesystem is full. I've noticed that in > the past, and opkg doesn't provide much in the way of feedback if/when > this happens. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] external variable
Hello everyone, Is there any way of defining a variable into a recipe and use it in another. I tried: export VAR="value" but when I tested it`s existence in devshell it did not exist(echo $VAR). Defining this variable in local.conf is not a viable solution. Thank you, Alex ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Busybox configuration example?
On 2013-10-17 13:49, Nicolas Dechesne wrote:
On Thu, Oct 17, 2013 at 3:50 PM, Gary Thomas wrote:
Can someone explain how I might control my busybox builds?
For example, I routinely add this to busybox*.bbappend:
#
# Force 'ifup' to wait longer for really slow links...
#
do_prepare_config_append () {
sed -i 's/CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R
-n"/CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R -n -T 1 -t 20"/' ${S}/.config
}
which is just editing the confguration file to match my preferences.
Is there a way to do this using the "configuration fragments" mentioned
above?
here is an example of busybox config fragment, that we use
https://git.linaro.org/gitweb?p=openembedded/meta-linaro.git;a=tree;f=meta-linaro/recipes-core/busybox;h=2c4a6b6b8b542b2eef04561d95a802d855ae7573;hb=master
i don't know if the config fragment would work for what you are
doing.. let us know ;-)
Thanks for the example. I added this simple config fragment and it works fine.
# Force 'ifup' to wait longer for really slow links...
CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R -n -T 1 -t 20"
Of course, the comment is stripped in the final configuration file, but it
documents the purpose of the fragment.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Busybox configuration example?
On Fri, Oct 18, 2013 at 3:09 PM, Gary Thomas wrote: > Thanks for the example. I added this simple config fragment and it works > fine. > > # Force 'ifup' to wait longer for really slow links... > CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R -n -T 1 -t 20" > Of course, the comment is stripped in the final configuration file, but it > documents the purpose of the fragment. thanks for the follow up! ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] preserving file owners in do_package
In data martedì 15 ottobre 2013 17:18:35, Paul Eggleton ha scritto:
> On Tuesday 15 October 2013 18:12:42 Davide Soldan wrote:
> > In data martedì 15 ottobre 2013 11:38:21, Paul Eggleton ha scritto:
> > > On Tuesday 15 October 2013 12:02:20 Davide Soldan wrote:
> > > > in my recipe I want to change owner and permission of a file, so I
> > > > wrote:
> > > >
> > > > do_install() {
> > > >
> > > > ls -la ${D}/opt/user
> > > > chown -R user ${D}/opt/user
> > > > chgrp -R user ${D}/opt/user
> > > > ls -la ${D}/opt/user
> > > > chmod 754 ${D}/opt/user/user.sh
> > > > ls -la ${D}/opt/user
> > > >
> > > > }
> > > >
> > > > the output of ls commands is:
> > > >
> > > > drwxr-xr-x 8 root root 4096 Oct 15 11:13 .
> > > > drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
> > > > -rw-r--r-- 1 *root root* 55753 Aug 2 08:48 user.sh
> > > >
> > > > drwxr-xr-x 8 user user 4096 Oct 15 11:13 .
> > > > drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
> > > > -rw-r--r-- 1 *user user* 55753 Aug 2 08:48 user.sh
> > > >
> > > > drwxr-xr-x 8 user user 4096 Oct 15 11:13 .
> > > > drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
> > > > *-rwxr-xr--* 1 user user 55753 Aug 2 08:48 user.sh
> > > >
> > > > So the change of owner and permission works fine in do_install phase.
> > > > Opening the final rootfs tarball, however, the file user.sh has still
> > > > 754
> > > > permission but root as owner...so do_package doesn't preserve owner
> > > > change
> > > > done in do_install? Or maybe I'm doing something wrong in changing file
> > > > owner? Any ideas? Thanks to all!
> > >
> > > Does your recipe create the specified user via useradd.bbclass?
> >
> > I solved with a postinstall script (that run at boot):
> >
> > pkg_postinst_${PN}() {
> > #!/bin/sh -e
> > if [ x"$D" = "x" ]; then
> > chown -R user /opt/user
> > chgrp -R user /opt/user
> > else
> > exit 1
> > fi
> > }
>
> This shouldn't be necessary though. I honestly can't tell you why it doesn't
> work as specified. I think it might be worth filing a bug for this.
>
> Cheers,
> Paul
>
>
I'm so sorry Paul, but my mail client missed your last email and so I filed a
bug uselessly...
I tried, as you suggested, to add the package that create the user to the
RDEPENDS_${PN} removing the postinstall scripi. That worked setting the right
owner with chown/chgrp in do_install...
Thank you so much. I very sorry for the useless bug opened...can I close it by
myself?
Cheers
Davide
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] preserving file owners in do_package
Hi Davide,
On Friday 18 October 2013 15:31:22 Davide Soldan wrote:
> In data martedì 15 ottobre 2013 17:18:35, Paul Eggleton ha scritto:
> > On Tuesday 15 October 2013 18:12:42 Davide Soldan wrote:
> > > In data martedì 15 ottobre 2013 11:38:21, Paul Eggleton ha scritto:
> > > > On Tuesday 15 October 2013 12:02:20 Davide Soldan wrote:
> > > > > in my recipe I want to change owner and permission of a file, so I
> > > > > wrote:
> > > > >
> > > > > do_install() {
> > > > >
> > > > > ls -la ${D}/opt/user
> > > > > chown -R user ${D}/opt/user
> > > > > chgrp -R user ${D}/opt/user
> > > > > ls -la ${D}/opt/user
> > > > > chmod 754 ${D}/opt/user/user.sh
> > > > > ls -la ${D}/opt/user
> > > > >
> > > > > }
> > > > >
> > > > > the output of ls commands is:
> > > > >
> > > > > drwxr-xr-x 8 root root 4096 Oct 15 11:13 .
> > > > > drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
> > > > > -rw-r--r-- 1 *root root* 55753 Aug 2 08:48 user.sh
> > > > >
> > > > > drwxr-xr-x 8 user user 4096 Oct 15 11:13 .
> > > > > drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
> > > > > -rw-r--r-- 1 *user user* 55753 Aug 2 08:48 user.sh
> > > > >
> > > > > drwxr-xr-x 8 user user 4096 Oct 15 11:13 .
> > > > > drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
> > > > > *-rwxr-xr--* 1 user user 55753 Aug 2 08:48 user.sh
> > > > >
> > > > > So the change of owner and permission works fine in do_install
> > > > > phase.
> > > > > Opening the final rootfs tarball, however, the file user.sh has
> > > > > still
> > > > > 754
> > > > > permission but root as owner...so do_package doesn't preserve owner
> > > > > change
> > > > > done in do_install? Or maybe I'm doing something wrong in changing
> > > > > file
> > > > > owner? Any ideas? Thanks to all!
> > > >
> > > > Does your recipe create the specified user via useradd.bbclass?
> > >
> > > I solved with a postinstall script (that run at boot):
> > >
> > > pkg_postinst_${PN}() {
> > >
> > > #!/bin/sh -e
> > > if [ x"$D" = "x" ]; then
> > >
> > > chown -R user /opt/user
> > > chgrp -R user /opt/user
> > >
> > > else
> > >
> > > exit 1
> > >
> > > fi
> > >
> > > }
> >
> > This shouldn't be necessary though. I honestly can't tell you why it
> > doesn't work as specified. I think it might be worth filing a bug for
> > this.
> >
> > Cheers,
> > Paul
>
> I'm so sorry Paul, but my mail client missed your last email and so I filed
> a bug uselessly... I tried, as you suggested, to add the package that
> create the user to the RDEPENDS_${PN} removing the postinstall scripi. That
> worked setting the right owner with chown/chgrp in do_install... Thank you
> so much. I very sorry for the useless bug opened...can I close it by
> myself?
I've marked it resolved. No problem about filing it, at least it's now there
for reference if anyone hits the same situation :)
I think it's fair to say we need to look at how to better document all of this
stuff in the manual. We could probably afford to dedicate a small section on
how
to deal with adding/modifying users and file ownership. Scott, could you add
this to your todo list?
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] external variable
Hi Alex, On Friday 18 October 2013 15:19:57 jan alexandru vaduva wrote: > Is there any way of defining a variable into a recipe and use it in another. > I tried: export VAR="value" but when I tested it`s existence in devshell it > did not exist(echo $VAR). No, this is not possible. The only way you can share data between recipes like this is to write it into a file within the sysroot, or rely on it being specified for both recipes at the configuration level (although you've suggested the latter won't work for your situation). Can you elaborate on what exactly you're trying to achieve? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] preserving file owners in do_package
In data venerdì 18 ottobre 2013 14:38:27, Paul Eggleton ha scritto:
> Hi Davide,
>
> On Friday 18 October 2013 15:31:22 Davide Soldan wrote:
> > In data martedì 15 ottobre 2013 17:18:35, Paul Eggleton ha scritto:
> > > On Tuesday 15 October 2013 18:12:42 Davide Soldan wrote:
> > > > In data martedì 15 ottobre 2013 11:38:21, Paul Eggleton ha scritto:
> > > > > On Tuesday 15 October 2013 12:02:20 Davide Soldan wrote:
> > > > > > in my recipe I want to change owner and permission of a file, so I
> > > > > > wrote:
> > > > > >
> > > > > > do_install() {
> > > > > >
> > > > > > ls -la ${D}/opt/user
> > > > > > chown -R user ${D}/opt/user
> > > > > > chgrp -R user ${D}/opt/user
> > > > > > ls -la ${D}/opt/user
> > > > > > chmod 754 ${D}/opt/user/user.sh
> > > > > > ls -la ${D}/opt/user
> > > > > >
> > > > > > }
> > > > > >
> > > > > > the output of ls commands is:
> > > > > >
> > > > > > drwxr-xr-x 8 root root 4096 Oct 15 11:13 .
> > > > > > drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
> > > > > > -rw-r--r-- 1 *root root* 55753 Aug 2 08:48 user.sh
> > > > > >
> > > > > > drwxr-xr-x 8 user user 4096 Oct 15 11:13 .
> > > > > > drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
> > > > > > -rw-r--r-- 1 *user user* 55753 Aug 2 08:48 user.sh
> > > > > >
> > > > > > drwxr-xr-x 8 user user 4096 Oct 15 11:13 .
> > > > > > drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
> > > > > > *-rwxr-xr--* 1 user user 55753 Aug 2 08:48 user.sh
> > > > > >
> > > > > > So the change of owner and permission works fine in do_install
> > > > > > phase.
> > > > > > Opening the final rootfs tarball, however, the file user.sh has
> > > > > > still
> > > > > > 754
> > > > > > permission but root as owner...so do_package doesn't preserve owner
> > > > > > change
> > > > > > done in do_install? Or maybe I'm doing something wrong in changing
> > > > > > file
> > > > > > owner? Any ideas? Thanks to all!
> > > > >
> > > > > Does your recipe create the specified user via useradd.bbclass?
> > > >
> > > > I solved with a postinstall script (that run at boot):
> > > >
> > > > pkg_postinst_${PN}() {
> > > >
> > > > #!/bin/sh -e
> > > > if [ x"$D" = "x" ]; then
> > > >
> > > > chown -R user /opt/user
> > > > chgrp -R user /opt/user
> > > >
> > > > else
> > > >
> > > > exit 1
> > > >
> > > > fi
> > > >
> > > > }
> > >
> > > This shouldn't be necessary though. I honestly can't tell you why it
> > > doesn't work as specified. I think it might be worth filing a bug for
> > > this.
> > >
> > > Cheers,
> > > Paul
> >
> > I'm so sorry Paul, but my mail client missed your last email and so I filed
> > a bug uselessly... I tried, as you suggested, to add the package that
> > create the user to the RDEPENDS_${PN} removing the postinstall scripi. That
> > worked setting the right owner with chown/chgrp in do_install... Thank you
> > so much. I very sorry for the useless bug opened...can I close it by
> > myself?
>
> I've marked it resolved. No problem about filing it, at least it's now there
> for reference if anyone hits the same situation :)
>
> I think it's fair to say we need to look at how to better document all of
> this
> stuff in the manual. We could probably afford to dedicate a small section on
> how
> to deal with adding/modifying users and file ownership. Scott, could you add
> this to your todo list?
>
> Cheers,
> Paul
>
>
Very good idea! When I was looking for information about how to add/modify
users and file ownership I missed a bit of official documentation!
Cheers
Davide
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] oe-selftest proof of concept
Hello, After a chat with Richard and Stefan, I came up with an outline of how the oe-selftest feature(https://bugzilla.yoctoproject.org/show_bug.cgi?id=4740 ) should look like. I made a summary of my proposal below. Please feel free to add your thoughts! There will be a new script introduced(similar to bitbake-selftest) that will use python unit test to execute tests. Name has not been decided but it can be "oe-selftest". Running this script will not compromise poky in any way. Initially, the script does not need any preparation in order to be run. If this changes in the future, the user will be prompted upon execution with the pre-required tasks. Oe-selftest can be used together with the automated runtime tests if necessary. The following types of tests are targeted for the initial implementation: - testing the functionality of scripts in poky/scripts (such as: bitbake-layers, yocto-bsp, yocto-kernel, yocto-layers) - testing of the 'bitbake' command and its output (this includes output data validation such as the sstate-cache/ and tmp/ directories) In order to achieve the above, the script will need to: - manipulate configuration files and variables - issue commands in a certain order - analyze command output - analyze output files and directories - manage shared resources such as sstate-cache Oe-selftest will use Python Unit Testing as follows: - we will use what has already been done with the 'unittest' and 'oeqa' classes. This includes 'decorators' and methods like 'skipModules'. - the tests configuration files will be similar to those of the automated runtime tests. - because we are using the same framework and structure, the output will also be similar to that of the automated runtime tests - the build environments used will be set up in the setUpClass() or setUpModule() methods * local.conf may be modified here to use shared resources like sstate-cache and downloads directory with other build environments - the build environments used will be removed in the tearDownClass() or tearDownModule() methods * this ensures no residue is left over that we are not aware of - we will add a new class oeqa.oeSelfTest that contains the following base methods: 1) A few methods to manipulate variables in poky in a standardized way: - oeSelfTest.var_rewrite(filepath_relative_to_poky_location, variable_name, new_variable_value) * resets a variable to the specified value(may be similar to how HOB does to local.conf and bblayers.conf) - oeSelfTest.var_append(filepath_relative_to_poky_location, variable_name, appended_variable_value) * appends data to a variable - oeSelfTest.var_remove(filepath_relative_to_poky_location, variable_name, remove_variable_value) * removes data from a variable 2) We need to be able to execute tasks in a multiple build directories environment. - oeSelfTest.execute(command, build_dir) * this method executes the command 'command' from 'build_dir' * for each execution, the environment is sourced (similar to autobuilder) (if the build directory does not exist, the command will fail. This needs to be taken care of in the setUpClass() method) * it returns the exit code and the output of the command Additional information/notes: - class and method naming and structure is not final and open for suggestions - poky under git is required for the script to work; we will use git to reset modified files to default. - a policy needs to be set in place(after experience has been gained from using the tool) for working with a shared sstate-cache directory and multiple build environments at a time. - coding style is very important in order to get a reasonable execution time. At the moment this is not a priority though. - no strategy has been put in place yet in order to deal with multiple poky environments ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] external variable
I am currently trying to copy using sed the variable into local.conf.
But: grep -q "^AAA=" ${BUILDDIR}/conf/local.conf && \
sed "s/^AAA=.*/AAA="${D}"/" -i ${BUILDDIR}/conf/local.conf || \
sed "$ a\AAA="${D}"" -i ${BUILDDIR}/conf/local.conf
Is giving me some errors, like:
ParseError: ParseError at
/media/sdc1/fb/alvd/test/buildToolchain/conf/local.conf:258: unparsed line:
'AAA=/media/sdc1/fb/alvd/test/buildToolchain/tmp/work/xxx-poky-linux/base-files/3.0.14-r73/image'
I`ll try resolving this error and remain with this solution because I can`t
seem to find a better one. For any ideas, here is my scenario:
My final scope is to copy from a kernel initramfs template some information
into rootfs.
I observed that base-files is creating the rootfs structure and I wanted to
copy the files in the /image location. to be available
into the final rootfs archive.
Alex
.
On Fri, Oct 18, 2013 at 4:41 PM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:
> Hi Alex,
>
> On Friday 18 October 2013 15:19:57 jan alexandru vaduva wrote:
> > Is there any way of defining a variable into a recipe and use it in
> another.
> > I tried: export VAR="value" but when I tested it`s existence in devshell
> it
> > did not exist(echo $VAR).
>
> No, this is not possible. The only way you can share data between recipes
> like
> this is to write it into a file within the sysroot, or rely on it being
> specified for both recipes at the configuration level (although you've
> suggested
> the latter won't work for your situation).
>
> Can you elaborate on what exactly you're trying to achieve?
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] oe-selftest proof of concept
I made an example of how we can use the functionality described to conduct 3 of
our test cases:
https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=90
https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=93
https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=83
As mentioned, the structure is very similar to the automated runtime tests
configuration files.
NOTE: ${POKYDIR} does not exist but I use it to refer to the location of the
poky directory.
"
import unittest
import os
from oeqa import oeSelfTest, skipModule
from oeqa.utils.decorators import *
def setUpModule():
# Here we set up the environment for a build directory
class bitbake_layers(oeSelfTest):
@classmethod
def setUpClass(self):
# Here we set up special settings for the build
environment, like shared sstate-cache directory
def test_show_overlayed(self):
oeSelfTest.execute("cp -R
${POKYDIR}/meta/recipes-graphics/clutter ${POKYDIR}/meta/recipes-core/")
(status, output) =
oeSelfTest.execute("bitbake-layers show_overlayed | grep clutter", build_dir)
oeSelfTest.execute("rm -R
${POKYDIR}/meta/recipes-core/clutter")
self.assertEqual(status, 0, msg="Could not find
overlayed recipe")
def test_show_appends(self):
oeSelfTest.execute("echo "" >
${POKYDIR}/meta-yocto/recipes-core/busybox/linux-yocto_3.10.bbappend"/")
(status, output) =
oeSelfTest.execute("bitbake_layers show_appends | grep
\"/meta-yocto/recipes-core/busybox/linux-yocto_3.10.bbappend\"", build_dir)
self.assertEqual(status, 0, msg="
'bitbake_layers show_appends' Could not find the bbappend file")
def test_show_layers(self):
(ls_status) = oeSelfTest.execute("ls ${POKYDIR}
| grep meta-intel")
if ls_status == 1:
(git_status) =
oeSelfTest.execute("git clone git://git.yoctoproject.org/meta-intel
${POKYDIR}/")
oeSelfTest.file.var.append("${BUILDDIR}/conf.bblayers.conf", "BBLAYERS",
"${POKYDIR}/meta-intel")
(status, output) =
oeSelfTest.execute("bitbake-layers show_layers | grep meta-intel", build_dir)
self.assertEqual(status, 0, msg="
'bitbake-layers show_layers ' could not find meta-intel layer in output")
@classmethod
def tearDownClass(self):
# Even though now it's not needed, here we can
reset the git repo in order to revert to default
oeSelfTest.execute("git reset --hard")
def tearDownModule():
# Here we remove the build directory
"
Regards,
Corneliu
Romania Yocto QA
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Stoicescu, CorneliuX
Sent: Friday, October 18, 2013 5:36 PM
To: yocto
Subject: [yocto] oe-selftest proof of concept
Hello,
After a chat with Richard and Stefan, I came up with an outline of how the
oe-selftest feature(https://bugzilla.yoctoproject.org/show_bug.cgi?id=4740 )
should look like. I made a summary of my proposal below. Please feel free to
add your thoughts!
There will be a new script introduced(similar to bitbake-selftest) that will
use python unit test to execute tests. Name has not been decided but it can be
"oe-selftest".
Running this script will not compromise poky in any way.
Initially, the script does not need any preparation in order to be run. If this
changes in the future, the user will be prompted upon execution with the
pre-required tasks.
Oe-selftest can be used together with the automated runtime tests if necessary.
The following types of tests are targeted for the initial implementation:
- testing the functionality of scripts in poky/scripts (such as:
bitbake-layers, yocto-bsp, yocto-kernel, yocto-layers)
- testing of the 'bitbake' command and its output (this includes output data
validation such as the sstate-cache/ and tmp/ directories)
In order to achieve the above, the script will need to:
- manipulate configuration files and variables
- issue commands in a certain order
- analyze command output
- analyze output files and directories
- manage shared resources such as sstate-cache
Oe-selftest will use Python Unit Testing as follows:
- we will use what has already been done with the 'unittest'
and 'oeqa' classes. This includes 'decorators' and methods like 'skipModules'.
- the tests configuration files will be similar to those of the
automated runtime tests.
- because we are using the same framework and structu
[yocto] uImage instead of zImage
hello all, I am trying to get a uImage instead of zImage My beagleboard before created a uImage now with dora I get a zImage. in the mega-manual I see the following . KERNEL_IMAGETYPE The type of kernel to build for a device, usually set by the machine configuration files and defaults to "zImage". This variable is used when building the kernel and is passed to make as the target to build. . /home/vidal/POKY/build101613_dora/poky/meta/conf/machine/include/arm/arch-arm.inc I have tried KERNEL_IMAGETYPE ?= "uImage" KERNEL_IMAGETYPE = "uImage" and nothing changes I still get a zImage. Also tried in local.conf Any and all help will be appreciated. Thanks ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] uImage instead of zImage
On Fri, 18 Oct 2013, Edward Vidal wrote: > hello all, > I am trying to get a uImage instead of zImage > My beagleboard before created a uImage now with dora I get a zImage. > > in the mega-manual I see the following . > > KERNEL_IMAGETYPE > > The type of kernel to build for a device, usually set by the machine > configuration files and defaults to "zImage". This variable is used when > building the kernel > and is passed to make as the target to build. is there a specific reason you want a uImage, given that a zImage is, these days, a better choice? after all, the current u-boot now, by default, will try to boot a zImage for the beaglebone. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Fwd: uImage instead of zImage
-- Forwarded message -- From: Robert P. J. Day Date: Fri, Oct 18, 2013 at 9:44 AM Subject: Re: [yocto] uImage instead of zImage To: Edward Vidal On Fri, 18 Oct 2013, Edward Vidal wrote: > Hello > When I changed the uEnv.txt file I get the same error. > I also have a zImage-omap3-beagle-xm.dtb which is new with this build is this the correct name. > MLO u-boot.img zImage uEnv.txt and zImage-omap3-beagle-xm.dtb are the files on my DOS partition. > Thanks you should not be emailing to me directly, you should respond to this on the mailing list so that others can benefit from the discussion. rday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to enable LTP support in "core-image-basic"
On Oct 18, 2013, at 12:17 AM, Amit Kumar wrote:
> Hi,
>I wants to use the LTP test suite provided by yocto project. But I
> don’t know how to enable it for “core-image-basic”.
> Can anyone help me to enable the LTP in “core-image-basic”?
Several ways to do it. In your local.conf you could add
CORE_IMAGE_EXTRA_INSTALL += "ltp"
You can also modify image recipe itself and add it to RDEPENDS
or write a bbappend to the image recipe in your layer and then
add RDEPEND_${PN} += "ltp" to it.
>
>
> Thanks & Regards
> Amit K
>
> The contents of this e-mail and any attachment(s) may contain confidential or
> privileged information for the intended recipient(s). Unintended recipients
> are prohibited from taking action on the basis of information in this e-mail
> and using or disseminating the information, and must notify the sender and
> delete it from their system. L&T Infotech will not accept responsibility or
> liability for the accuracy or completeness of, or the presence of any virus
> or disabling code in this e-mail"
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Announcement] Yocto Project 1.5 now available.
All, The latest major release of the Yocto Project, 1.5 "Dora" (poky-10.0.0), is now available for download at: * http://downloads.yoctoproject.org/releases/yocto/yocto-1.5/poky-dora-10.0.0.tar.bz2 * http://mirrors.kernel.org/yocto/yocto/yocto-1.5/poky-dora-10.0.0.tar.bz2 Improvements over the Yocto Project 1.4 "dylan" Release include: * Major performance improvements * 180+ recipe upgrades * New x86 and x86-64 reference BSPs * Over 400 bugs fixed Errata and Downloads Release Name: poky-dora-10.0.0 Branch: dora Tag: dora-10.0.0.final Hash: faf8f8660fae26a14578738b642fdeb08bcb9d54 md5: 53dd6fdbbf1f5a5b432af15ab9d0da13 Download Locations: * http://downloads.yoctoproject.org/releases/yocto/yocto-1.5/poky-dora-10.0.0.tar.bz2 * http://mirrors.kernel.org/yocto/yocto/yocto-1.5/poky-dora-10.0.0.tar.bz2 Release Name: meta-qt3-dora-10.0.0 Branch: dora Tag: dora-10.0.0.final Hash: b73552fb998fd30a01dbee5a172e432a16078222 md5: 1f679807beff534f1ec29bac227db034 Download Locations: * http://downloads.yoctoproject.org/releases/yocto/yocto-1.5/meta-qt3-dora-10.0.0.tar.bz2 * http://mirrors.kernel.org/yocto/yocto/yocto-1.5/meta-qt3-dora-10.0.0.tar.bz2 Release Name: eclipse-poky-juno-dora-10.0.0 Branch: dora Tag: dora-10.0.0.final Hash: 2fa1c58940141a3c547c8790b8a6832167e8eb66 md5: 7351df2f38dd80cd36aeb3a68f8b42cf Download Locations: * http://downloads.yoctoproject.org/releases/yocto/yocto-1.5/eclipse-poky-juno-dora-10.0.0.tar.bz2 * http://mirrors.kernel.org/yocto/yocto/yocto-1.5/eclipse-poky-juno-dora-10.0.0.tar.bz2 Release Name: eclipse-poky-kepler-dora-10.0.0 Branch: dora Tag: dora-10.0.0.final Hash: ad74249895f882a8f00bdeef7a0f7c18998cc43e md5: d9cceb07cdadde1d6263c5b25ab570f5 Download Locations: * http://downloads.yoctoproject.org/releases/yocto/yocto-1.5/eclipse-poky-kepler-dora-10.0.0.tar.bz2 * http://mirrors.kernel.org/yocto/yocto/yocto-1.5/eclipse-poky-kepler-dora-10.0.0.tar.bz2 Release Name: yocto-autobuilder-dora-10.0.0 Branch: dora Tag: dora-10.0.0.final Hash: 1a86156016e2cfbb1fc0c3e28b03d247cb9038d2 md5: e030b33211ba237a263ec6ec479d9f30 Download Locations: * http://downloads.yoctoproject.org/releases/yocto/yocto-1.5/yocto-autobuilder-dora-10.0.0.tar.bz2 * http://mirrors.kernel.org/yocto/yocto/yocto-1.5/yocto-autobuilder-dora-10.0.0.tar.bz2 The QA report is available at: * https://wiki.yoctoproject.org/wiki/WW41_-_2013-10-08_-_Full_Pass_Release_1.5_M5.rc8 Features * linux-yocto 3.10 kernel * gcc 4.8.1 * eglibc 2.18 * 180+ other recipe upgrades * Improvements in bitbake startup and parse time ( ~25% improvement in startup time, ~10% improvement in overall parse time) * Eclipse plug-in added CMake project support and is upgraded to Kepler release. The code base has also gone through major refactoring to better support remote interaction. * Added gstreamer 1.0 (default version built is still 0.10) * Added bluez 5 (default version built is still 4) * New genericx86 / genericx86-64 hardware reference BSPs replacing atom-pc * New "buildtools-tarball" providing certain tools (python, git, chrpath, tar, make) for host distributions whose own versions of those tools are broken or too old to be compatible with the build system * New automated runtime testing framework to run tests written in Python on images using QEMU * Support for /run from FHS 3 draft specification * BusyBox binary is now split into suid and non-suid portions, allowing the replacement of tinylogin * Added ability to easily build initramfs binaries (kernel + initramfs image) and pair a rootfs image recipe with an initramfs image recipe * Added ability to explicitly exclude one or more packages from an image * Implementation of the tardis bbclass (Time And Relative DIsk Space) which allows disk images to take up an unlimited amount of space on limited disk space. * Image creation now creates real ext3/ext4 filesystem images instead of creating as ext2 and upgrading * Initial support for partitioning and advanced image creation (using new "wic" script) * Added inc file to enable compiler and linker flags that enhance security (conf/distro/include/security_flags.inc) * Properly split SDKs for different machines that have the same/similar architecture * Added a "test-dependencies" script to detect missing or auto-enabled dependencies * Added ability to define additional users for an image not associated with a specific package (EXTRA_USERS_PARAMS) * Enabled ptest for ethtool, libxml2, perl, busybox, bzip2, python, kmod, bash (GPLv2 version), strace * Easier customisation of DISTRO_FEATURES if building your custom distro configuration on top of poky.conf * Added EFI support to ISO
Re: [yocto] Custom defconfig is not used
On 13-10-18 05:17 AM, Diego Sueiro wrote:
2013/10/18 Bruce Ashfield mailto:bruce.ashfi...@windriver.com>>
I fell behind today .. i had 2300 unread email to start this morning :)
Is there a way that I can get a copy of your recipes and layers ? If
I can do a build myself, I can easily debug and fix this ..
otherwise, we'll
go back and forth many times debugging.
Cheers,
Bruce
I'm using the environment provided by Angstrom from it's github setup
scripts.
If you want to exactly reproduce it you need to:
git clone https://github.com/Angstrom-distribution/setup-scripts.git
cd setup-scripts
git checkout angstrom-v2013.06-yocto1.4
MACHINE=beaglebone ./oebb.sh config beaglebone
Here is the setup and files for meta-mine:
bblayers.conf:
BBLAYERS = \"
...
${TOPDIR}/sources/meta-mine \
"
meta-mine/conf/layer.conf:
# We have a conf and classes directory, append to BBPATH
BBPATH .= ":${LAYERDIR}"
# We have a recipes directory, add to BBFILES
BBFILES += "${LAYERDIR}/recipes*/*/*.bb
${LAYERDIR}/recipes*/*/*.bbappend"
BBFILE_COLLECTIONS += "mine-layer"
BBFILE_PATTERN_mine-layer := "^${LAYERDIR}/"
BBFILE_PRIORITY_mine-layer = "10"
LAYERDEPENDS_mine-layer = "angstrom-layer"
meta-mine/recipes-kernel/linux/linux-mainline_3.8.bbappend:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
SRC_URI += " file://config-addons.cfg "
meta-mine/recipes-kernel/linux/linux-mainline-3.8/config-addons.cfg:
CONFIG_WATCHDOG_NOWAYOUT=y
CONFIG_NTFS_FS=y
CONFIG_NTFS_RW=y
But I think that instead of using the whole Angstrom you can just use
poky and meta-beagleboard/common-bsp on dylan branch.
Great. I'll launch some test builds and see what breaks (or works) :)
Bruce
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] Documentation: Correct error in FILESEXTRAPATHS_prepend example
FILESEXTRAPATHS_prepend example is missing essential trailing colon.
Signed-off-by: Robert P. J. Day
---
diff --git a/documentation/kernel-dev/kernel-dev-common.xml
b/documentation/kernel-dev/kernel-dev-common.xml
index 11a527c..a152f9f 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -95,7 +95,7 @@
FILESEXTRAPATHS
variable as follows:
- FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}"
+ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
The path ${THISDIR}/${PN}
expands to "linux-yocto" in the current directory for this
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-selinux] glib-2.0: upgrade from version 2.36.4 to 2.38.0
--- recipes-core/glib-2.0/glib-2.0_2.36.4.bbappend |1 - recipes-core/glib-2.0/glib-2.0_2.38.0.bbappend |1 + 2 files changed, 1 insertion(+), 1 deletion(-) delete mode 100644 recipes-core/glib-2.0/glib-2.0_2.36.4.bbappend create mode 100644 recipes-core/glib-2.0/glib-2.0_2.38.0.bbappend diff --git a/recipes-core/glib-2.0/glib-2.0_2.36.4.bbappend b/recipes-core/glib-2.0/glib-2.0_2.36.4.bbappend deleted file mode 100644 index 8c11cac..000 --- a/recipes-core/glib-2.0/glib-2.0_2.36.4.bbappend +++ /dev/null @@ -1 +0,0 @@ -inherit enable-selinux diff --git a/recipes-core/glib-2.0/glib-2.0_2.38.0.bbappend b/recipes-core/glib-2.0/glib-2.0_2.38.0.bbappend new file mode 100644 index 000..8c11cac --- /dev/null +++ b/recipes-core/glib-2.0/glib-2.0_2.38.0.bbappend @@ -0,0 +1 @@ +inherit enable-selinux -- 1.7.10.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
