[yocto] Which package provides reboot.target and shudown.target
Hi, I am using systemd in my target, Currently I am using "reboot -f" to reboot the system, i don't want to reboot like that. I am not able to reboot my system by simply using "reboot" , because I am using systemd not sysvinit. In sysvinit it internally calls "telinit" (or) "shutdown" with runlevels(0-6) , But both are absent in my case . I am using reboot command form "busybox". I dont know whether "reboot" command is provided from any other package. Can any one suggest me how can i use just "reboot" to reboot my system. I am using Yocto build setup (poky 1.7) for this. I found that systemd provides some runlevels similar to sysvinit as given below https://www.freedesktop.org/software/systemd/man/systemd.special.html Does any one can tell which recipe provides these target files. Any help is appreciated . Thanks and Regards Vivek -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Howto change the default shell in yocto?
Hello, how can I change the default shell on the yocto target from bash to another shell like dash? is there a variable for local.conf? or do I need to adapt my passwd for every user? Best Regards, Oliver -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Howto change the default shell in yocto?
The default *system* shell (/bin/sh) or the default shell for users, or for root? Folks often conflate them, but they're not the same. On Fri, Mar 4, 2016 at 7:01 AM Oliver Graute wrote: > Hello, > > how can I change the default shell on the yocto target from bash to > another shell like dash? > > is there a variable for local.conf? or do I need to adapt my passwd for > every user? > > Best Regards, > > Oliver > -- > ___ > 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] Native packages compiled with host gcc set in PATH and with LD_LIBRARY_PATH to libstd++
Hi,
I have set newer gcc(4.9) in PATH and with proper LD_LIBRARY_PATH. Default
system gcc is 4.4.
Bulding cmake-native fails when bootstrap cmake tries to compile cmake
native binary.
This is due to the fact that bootstrap was compiled with newer glibcxx and
it can't be found in system/host /usr/lib, /usr/lib64 nor in -rpath.
rpath is set to
-Wl,-rpath,${STAGING_LIBDIR_NATIVE} \
-Wl,-rpath,${STAGING_BASE_LIBDIR_NATIVE} \
from BUILD_LDFLAGS var in bitbake.conf which is expand in native class.
What is the correct approach to fix this ? Or I shouldn't use gcc from PATH
for compilation of native packages ?
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project Status WW10
Current Dev Position: YP 2.1 M4 (Stabilization only milestone.) Next Deadline: YP 2.1 M3 Target release date is March 18, 2016 SWAT team rotation: Alejandro -> Jussi https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: *M3 is proving a challenge to stabilize. There was a separate email discussing the various challenges we've had so far. There are several remaining issues with various patches including gobject-introspection, rpm upgrade, eSDK, uninative and prelink as well as some 'random' failures. We're continuing to work through these and expect to have an M3 build early next week. *Right now we don't have fixes for the prelink issue (which breaks glib and hence sato) and this will block M3 until resolved. *We're likely to propose we default to using uninative in poky and provide an include file other distros can use too. *We're now past feature freeze so no more feature development for 2.1 will be considered. *The 2.0.1-rc7 build has finished QA and is likely to be finally released. Key YP 2.1 Dates: YP 2.1 M3 Target release date is March 18, 2016 YP 2.1 M4 / Final Cutoff: March 28, 2016 noon GMT - Stabilization only milestone. YP 2.1 Final Release Target: April 29, 2016 Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.1_Status https://wiki.yoctoproject.org/wiki/Yocto_2.1_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.1_Features Tracking Metrics: WDD 2577 (last week 2565 ) (https://wiki.yoctoproject.org/charts/combo.html) [If anyone has suggestions for other information you'd like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 * Work Telephone:(503) 712-0534 *Cell: (208) 244-4460 * Email:stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] documentation: remove all references to Hob
From: Belen Barros Pena Hob and the packageinfo class have now been removed from the code base. This patch removes all references to: * Hob * meta-hob * packageinfo and * BBLAYERS_NON_REMOVABLE from the documentation. So long, Hob, and thanks for all the fish. Signed-off-by: Belen Barros Pena --- documentation/bsp-guide/bsp.xml| 5 -- documentation/dev-manual/dev-manual-intro.xml | 5 -- documentation/dev-manual/dev-manual-model.xml | 47 --- documentation/ref-manual/introduction.xml | 4 -- documentation/ref-manual/migration.xml | 14 +- documentation/ref-manual/ref-bitbake.xml | 2 +- documentation/ref-manual/ref-classes.xml | 16 --- documentation/ref-manual/ref-structure.xml | 3 +- documentation/ref-manual/ref-variables.xml | 54 -- .../toaster-manual/toaster-manual-intro.xml| 19 10 files changed, 3 insertions(+), 166 deletions(-) diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml index ec39ec9..8cf2a1e 100644 --- a/documentation/bsp-guide/bsp.xml +++ b/documentation/bsp-guide/bsp.xml @@ -1403,11 +1403,6 @@ /usr/local/src/yocto/meta-yocto-bsp \ /usr/local/src/yocto/meta-myarm \ " - - BBLAYERS_NON_REMOVABLE ?= " \ -/usr/local/src/yocto/meta \ -/usr/local/src/yocto/meta-yocto \ -" Adding the layer to this file allows the build system to build the BSP and the yocto-kernel tool to be able to find the layer and diff --git a/documentation/dev-manual/dev-manual-intro.xml b/documentation/dev-manual/dev-manual-intro.xml index e350882..5affa86 100644 --- a/documentation/dev-manual/dev-manual-intro.xml +++ b/documentation/dev-manual/dev-manual-intro.xml @@ -169,11 +169,6 @@ release of the Yocto Project. -Hob: -A graphical user interface for BitBake. -Hob's primary goal is to enable a user to perform common tasks more easily. - - Toaster: An Application Programming Interface (API) and web-based interface to the OpenEmbedded build system, which uses diff --git a/documentation/dev-manual/dev-manual-model.xml b/documentation/dev-manual/dev-manual-model.xml index 984d08d..489547d 100644 --- a/documentation/dev-manual/dev-manual-model.xml +++ b/documentation/dev-manual/dev-manual-model.xml @@ -48,12 +48,6 @@ Toaster provides an efficient interface to the OpenEmbedded build that allows you to start builds and examine build statistics. - Image Development using Hob: - You can use the Hob - to build custom operating system images within the build - environment. - Hob provides an efficient interface to the OpenEmbedded build system. - Using a Development Shell: You can use a devshell to efficiently debug commands or simply edit packages. @@ -3189,47 +3183,6 @@ - -Image Development Using Hob - - -The Hob is a graphical user interface for the -OpenEmbedded build system, which is based on BitBake. -You can use the Hob to build custom operating system images within the Yocto Project build environment. -Hob simply provides a friendly interface over the build system used during development. -In other words, building images with the Hob lets you take care of common build tasks more easily. - - - -For a better understanding of Hob, see the project page at - -on the Yocto Project website. -If you follow the "Documentation" link from the Hob page, you will -find a short introductory training video on Hob. -The following lists some features of Hob: - -You can setup and run Hob using these commands: - - $ source oe-init-build-env - $ hob - -You can set the -MACHINE -for which you are building the image. -You can modify various policy settings such as the -package format with which to build, -the parallelism BitBake uses, whether or not to build an -external toolchain, and which host to build against. - -You can manage -layers. -You can select a base image and then add extra packages for your custom build. - -You can launch and monitor the build from within Hob. - - - - Using a Development Shell diff --git a/documentation/ref-manual/introduction.xml b/documentation/ref-manual/introductio
[yocto] recommended structure to design a layer for multiple kernels and somewhat-related machines?
i just want some confirmation that i'm on the right track for designing a
BSP layer to handle a particular combination of kernel versions and machines,
so all i'm after is mostly a, "yeah, that's how i'd do it," or a, "no,
that's idiotic."
the situation -- handle all possible combinations of:
* two kernel versions (say, 4.0 and 4.1)
* three machines:
* m1 (based on powerpc mpc8260)
* m2a, m2b (two closely related machines, based on mpc8360)
the additional wrinkle there is that, although there are three machines,
two of them are closely-related enough that there is the possibility that
.scc, .cfg or .patch files could apply in the following ways.
first, they could apply to a specific version of the kernel, or to any
version. no problem, that's easy.
regarding machines, those patches could possibly apply to:
* a single, specific machine
* all machines
* just to the mpc8360-based machines
so here's my idea.
in a linux.inc file, have the lines:
FILESEXTRAPATHS_prepend := "${THISDIR}/${BP}:${THISDIR}/${BPN}:"
MACHINEOVERRIDES_prepend_m2a = "mpc8360:"
MACHINEOVERRIDES_prepend_m2b = "mpc8360:"
that first line obviously extends my search path based on the kernel
version to look in (say, for kernel 4.0) in:
* linux-4.0/
* linux/
those next two lines deal with the fact that, for powerpc in this case,
with:
FILESOVERRIDES=${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}
TRANSLATED_TARGET_ARCH = "powerpc"
MACHINEOVERRIDES = "machine name"
so between the two of them, i want to sneak in "mpc8360" so that the search
order is specific machine, followed by the more general "mpc8360". sound good
so far?
next, for full flexibility, i can define three .bbappend files:
* linux_4.1.bbappend
* linux_4.0.bbappend
* linux_%.bbappend
since (as bruce mentioned recently), *all* matching bbappend files will
be processed in the (hopefully) intuitive order. (not sure i'll need that
wildcard .bbappend file, but i'll keep it in reserve, just in case.)
and, ***finally***, given all of the above, i'll have three directories
for SRC_URI items:
* linux-4.1/
* linux-4.0/
* linux/
where each directory will have the internal substructure:
* m1/
* m2a/
* m2b/
* mpc8360/
given all of the above, i think i've covered every conceivable possibility
for when patches might be applied. have i missed anything? is there an
easier way to do this?
rday
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] documentation: remove all references to Hob
On 3/4/16 8:49 AM, Belen Barros Pena wrote: > From: Belen Barros Pena > > Hob and the packageinfo class have now been removed from the code base. > This patch removes all references to: > > * Hob > * meta-hob > * packageinfo and > * BBLAYERS_NON_REMOVABLE > > from the documentation. the build appliance page refers to HOB. does it need to updated? https://www.yoctoproject.org/documentation/build-appliance-manual - armin > > So long, Hob, and thanks for all the fish. > > Signed-off-by: Belen Barros Pena > --- > documentation/bsp-guide/bsp.xml| 5 -- > documentation/dev-manual/dev-manual-intro.xml | 5 -- > documentation/dev-manual/dev-manual-model.xml | 47 --- > documentation/ref-manual/introduction.xml | 4 -- > documentation/ref-manual/migration.xml | 14 +- > documentation/ref-manual/ref-bitbake.xml | 2 +- > documentation/ref-manual/ref-classes.xml | 16 --- > documentation/ref-manual/ref-structure.xml | 3 +- > documentation/ref-manual/ref-variables.xml | 54 > -- > .../toaster-manual/toaster-manual-intro.xml| 19 > 10 files changed, 3 insertions(+), 166 deletions(-) > > diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml > index ec39ec9..8cf2a1e 100644 > --- a/documentation/bsp-guide/bsp.xml > +++ b/documentation/bsp-guide/bsp.xml > @@ -1403,11 +1403,6 @@ > /usr/local/src/yocto/meta-yocto-bsp \ > /usr/local/src/yocto/meta-myarm \ > " > - > - BBLAYERS_NON_REMOVABLE ?= " \ > -/usr/local/src/yocto/meta \ > -/usr/local/src/yocto/meta-yocto \ > -" > > Adding the layer to this file allows the build system to > build the BSP and > the yocto-kernel tool to be able to > find the layer and > diff --git a/documentation/dev-manual/dev-manual-intro.xml > b/documentation/dev-manual/dev-manual-intro.xml > index e350882..5affa86 100644 > --- a/documentation/dev-manual/dev-manual-intro.xml > +++ b/documentation/dev-manual/dev-manual-intro.xml > @@ -169,11 +169,6 @@ > release of the Yocto Project. > > > - url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob: > -A graphical user interface for BitBake. > -Hob's primary goal is to enable a user to perform common > tasks more easily. > - > - > url='&YOCTO_HOME_URL;/tools-resources/projects/toaster'>Toaster: > An Application Programming Interface (API) and web-based > interface to the OpenEmbedded build system, which uses > diff --git a/documentation/dev-manual/dev-manual-model.xml > b/documentation/dev-manual/dev-manual-model.xml > index 984d08d..489547d 100644 > --- a/documentation/dev-manual/dev-manual-model.xml > +++ b/documentation/dev-manual/dev-manual-model.xml > @@ -48,12 +48,6 @@ > Toaster provides an efficient interface to the OpenEmbedded > build > that allows you to start builds and examine build statistics. > > - Image Development using Hob: > - You can use the url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob > - to build custom operating system images within the build > - environment. > - Hob provides an efficient interface to the OpenEmbedded build > system. > - > Using a Development Shell: > You can use a devshell to efficiently debug > commands or simply edit packages. > @@ -3189,47 +3183,6 @@ > > > > - > -Image Development Using Hob > - > - > -The url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob is a > graphical user interface for the > -OpenEmbedded build system, which is based on BitBake. > -You can use the Hob to build custom operating system images within > the Yocto Project build environment. > -Hob simply provides a friendly interface over the build system used > during development. > -In other words, building images with the Hob lets you take care of > common build tasks more easily. > - > - > - > -For a better understanding of Hob, see the project page at > - > -on the Yocto Project website. > -If you follow the "Documentation" link from the Hob page, you will > -find a short introductory training video on Hob. > -The following lists some features of Hob: > - > -You can setup and run Hob using these commands: > - > - $ source oe-init-build-env > - $ hob > - > -You can set the > - url='&YOCTO_DOCS_REF_URL;#var-MACHINE'>MACHINE > -for which you are bui
[yocto] btrfs-tools Requires libgcc_s.so.1
I'm building an image using btrfs and I noticed a problem with the btrfs-tools recipe in Jethro (using core-image-minimal and a 64-bit machine). The recipe builds fine, but I get the following error when attempting certain operations using btrfs, such as trying to start a scrub: root@test:~# btrfs scrub start / scrub started on /, fsid 79dc4fed-a0f7-43e2-b9e7-056b1a2c4cdd (pid=333) libgcc_s.so.1 must be installed for pthread_cancel to work I can solve this by adding libgcc to RDEPENDS for btrfs-tools. I'm not very familiar with libgcc, but is this just an oversight, or is there some reason it was not included? Should it be statically linked instead? Thanks, -- Robert Joslyn Software Engineer, R&D - Automation Schweitzer Engineering Laboratories 509-332-1890 ext. 3214 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] btrfs-tools Requires libgcc_s.so.1
On Sat, Mar 5, 2016 at 7:17 AM, wrote: > I'm building an image using btrfs and I noticed a problem with the > btrfs-tools recipe in Jethro (using core-image-minimal and a 64-bit > machine). The recipe builds fine, but I get the following error when > attempting certain operations using btrfs, such as trying to start a > scrub: > > root@test:~# btrfs scrub start / > scrub started on /, fsid 79dc4fed-a0f7-43e2-b9e7-056b1a2c4cdd (pid=333) > libgcc_s.so.1 must be installed for pthread_cancel to work > > I can solve this by adding libgcc to RDEPENDS for btrfs-tools. thats fine. I'm not > very familiar with libgcc, but is this just an oversight, or is there some > reason it was not included? its dlopened in this case I think thats why it has to explicitly called out as rdep. Should it be statically linked instead? no -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Which package provides reboot.target and shudown.target
On Fri, Mar 4, 2016 at 5:25 PM, Vivek Per wrote: > Hi, >I am using systemd in my target, Currently I am using "reboot > -f" to reboot the system, i don't want to reboot like that. I am not able to > reboot my system by simply using "reboot" , because I am using systemd not > sysvinit. In sysvinit it internally calls "telinit" (or) "shutdown" with > runlevels(0-6) , But both are absent in my case . I am using reboot command > form "busybox". I dont know whether "reboot" command is provided from any > other package. Can any one suggest me how can i use just "reboot" to reboot > my system. I am using Yocto build setup (poky 1.7) for this. >I found that systemd provides some runlevels similar to sysvinit as > given below > https://www.freedesktop.org/software/systemd/man/systemd.special.html > Does any one can tell which recipe provides these target files. Any help is > appreciated . user systemctl reboot > > > Thanks and Regards >Vivek > > > -- > ___ > 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] btrfs-tools Requires libgcc_s.so.1
Khem Raj wrote on 03/04/2016 03:26:37 PM:
>
> On Sat, Mar 5, 2016 at 7:17 AM, wrote:
> > I'm building an image using btrfs and I noticed a problem with the
> > btrfs-tools recipe in Jethro (using core-image-minimal and a 64-bit
> > machine). The recipe builds fine, but I get the following error when
> > attempting certain operations using btrfs, such as trying to start a
> > scrub:
> >
> > root@test:~# btrfs scrub start /
> > scrub started on /, fsid 79dc4fed-a0f7-43e2-b9e7-056b1a2c4cdd
(pid=333)
> > libgcc_s.so.1 must be installed for pthread_cancel to work
> >
> > I can solve this by adding libgcc to RDEPENDS for btrfs-tools.
>
> thats fine.
What is the process for getting this fixed upstream? Trivial patch is
below, if that is sufficient.
Signed-off-by: Robert Joslyn
---
diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb
b/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb
index 37c622b..cc2ccfc 100644
--- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb
+++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb
@@ -11,6 +11,7 @@ LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=fcb02dc552a041dee27e4b85c7396067"
SECTION = "base"
DEPENDS = "util-linux attr e2fsprogs lzo acl"
+RDEPENDS_${PN} = "libgcc"
SRCREV = "7f1328ccb5d159efe850d4eaea9b49bbe8c4181e"
SRC_URI =
"git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git \
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] btrfs-tools Requires libgcc_s.so.1
On 5 March 2016 at 00:12, wrote: > What is the process for getting this fixed upstream? Trivial patch is > below, if that is sufficient. > Would you be able to send that to the oe-core list ( openembedded-c...@lists.openembedded.org) using git-send-email (ideally, attaching the output of git format-patch will do) to get your authorship transferred correctly? That's the formal process. Thanks, Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] btrfs-tools Requires libgcc_s.so.1
"Burton, Ross" wrote on 03/04/2016 04:17:53 PM: > Would you be able to send that to the oe-core list (openembedded- > c...@lists.openembedded.org) using git-send-email (ideally, > attaching the output of git format-patch will do) to get your > authorship transferred correctly? That's the formal process. Sure, I'll send it along. Thanks, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
