Re: [yocto] How to use different busybox defconfig's in the initramfs and rootfs image

[ChenQi]

On 02/03/2015 05:23 PM, erwin.rieger@rohde-schwarz.com wrote:


Hello,

thank you for your reply.

I have a working solution now, but it is not as clean as i would like 
it to be and some new questions arose with it.


My current setup consists of a busybox.bbappend file that is used to 
customize the rootfs
busybox (defconfig, some /etc files and so on) and a 
busybox-initramfs.bb recipe for the initramfs busybox (as you

suggested).

The busybox.bbappend (see below) is straight forward, so no problem 
with that.


To create the busybox-initramfs.bb in my custom layer, i have included 
the base busybox recipe from the meta layer with

an 'require' statement.

Then i had to extend the FILESEXTRAPATHS variable to point back to the 
base recipe files-directory since it
no longer found the SRC_URI files from meta/busybox.bb and 
meta/busybox.inc. See the BUSYBOXBASEDIR

variable in the busybox-initramfs.bb below.

I feel that his construct is not that elegant, so here comes the 
f*irst question*:


Is there a nicer/cleaner way to include/reference the source files 
from the base busybox recipe in the meta layer?




How about using "${COREBASE}/meta/recipes-core/busybox"? I didn't try it 
out, so I'm not sure whether it works.


The *second question* concerns the versioning: The busybox.bbappend 
file uses a 'version wildcard' (_%) to
match all versions of the base busybox recipe. But in 
the busybox-initramfs.bb recipe i have to hardwire the

version of the base recipe.

How about change the recipe name to busybox-initramfs_1.22.1.bb? So that 
the PV value is automatically extracted from the recipe name and there's 
no need to set it in the recipe.



How can i use a 'version wildcard' in a 'require' statement?



It's not supported, as far as I know.

Best Regards,
Chen Qi

I've tried 'require recipes-core/busybox/busybox_%.bb' but that gives 
me a parse error so it seems not to be

possible to use version wildcards together with require/include.


My current busybox-initramfs.bb recipe:

---
DESCRIPTION = "Use different busybox defconfig for initramfs."

# require recipes-core/busybox/busybox_1.22.1.bb

PV = "1.22.1"
require recipes-core/busybox/busybox_${PV}.bb

S = "${WORKDIR}/busybox-${PV}"

# Point FILESPATH to base busybox files dir
BUSYBOXBASEDIR = "${THISDIR}/../../../meta/recipes-core/busybox"
FILESEXTRAPATHS_prepend := "${BUSYBOXBASEDIR}/busybox:"
FILESEXTRAPATHS_prepend := "${BUSYBOXBASEDIR}/files:"

# Include our initramfs busybox defconfig
FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"

BUSYBOX_SPLIT_SUID = "0"
---



The busybox_%.bbappend for the rootfs busybox:

---
DESCRIPTION = "Customize busybox."

# Include our rootfs busybox defconfig
FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"

SRC_URI += " \
file://inetd.conf \
"

do_install_append() {
install ${WORKDIR}/inetd.conf ${D}${sysconfdir}
}

BUSYBOX_SPLIT_SUID = "0"
---


Best Regards, Erwin Rieger



-ChenQi  schrieb: -
An: , 
Von: ChenQi 
Datum: 03.02.2015 02:48
Betreff: Re: [yocto] How to use different busybox defconfig's in the 
initramfs and rootfs image


The only way I know is to make a new recipe, busybox-initramfs.bb, for 
example.

Install busybox for image rootfs and busybox-initramfs for initramfs.

Best Regards,
Chen Qi

On 02/02/2015 09:21 PM, erwin.rieger@rohde-schwarz.com wrote:

Hello list,

i have used Yocto to create a initramfs linux kernel and a 
corresponding rootfs for a embedded linux system.


Things are working as expected, so far.

Now i want to fine-tune my setup and want to use a different busybox 
configuration in the initramfs as the one in the rootfs image.
For example, the initramfs busybox should contain support for 
switch-root and that is not needed in the rootfs.
On the other hand, the rootfs should contain a "full-fledged" busybox 
(with inetd enabled, for example).


So the question is: How can i build/install a package two times with 
differing configurations in one bitbake run?.


How can this be done the Yocto-way without copying busybox.bb and 
hacking it the way i need it?


I've tried various combinations, e.g. bb-appending busybox, 
inheriting from busybox and so on - but to no avail.


Maybe someone have an idea on how to do that?


PS:
* The kernel recipe is derived (bbappend) 
from core-image-minimal-initramfs.

* Rootfs recipe is derived from core-image-minimal.bb.


--
Erwin Rieger
--








-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Compile issue with 1.7 SDK and hf

[Mark Hatle]

On 1/29/15 3:35 AM, Teresa Gámez wrote:
> Hello,
> 
> I have installed a SDK based on yocto 1.7 with
> DEFAULTTUNE ?="cortexa8thf-neon" set. 
> 
> I have tried to compile the barebox bootloader with this
> SDK like this:
> 
> source 
> /opt/poky/1.7/environment-setup-cortexa8t2hf-vfp-neon-poky-linux-gnueabi
> unset LDFLAGS
> make am335x_defconfig
> Also enabled a barebox target tool in menuconfig: BAREBOXENV_TARGET 
> make

It looks like the tool you are trying to build is not using the full $CC,
otherwise the necessary ABI and related hardfloat parameters would be passed..
(alternatively if the component is adding it's own soft-float ABI values that
could also result in the failure.)

Generally the hard float toolchain does not have all of the code in place to
produce a soft-float binary as the executables have a different (incompatible) 
ABI.

> And see following compile error:
> 
> ..
>   CC  scripts/bareboxenv-target
> In file included
> from 
> /opt/poky/1.7/sysroots/cortexa8t2hf-vfp-neon-poky-linux-gnueabi/usr/include/features.h:389:0,
> 
> from 
> /opt/poky/1.7/sysroots/cortexa8t2hf-vfp-neon-poky-linux-gnueabi/usr/include/stdio.h:27,
>  from scripts/bareboxenv.c:20:
> /opt/poky/1.7/sysroots/cortexa8t2hf-vfp-neon-poky-linux-gnueabi/usr/include/gnu/stubs.h:7:29:
>  fatal error: gnu/stubs-soft.h: No such file or directory
>  # include 
> ^
> compilation terminated.
> 
> I have tried the same with other non yocto hf toolchains. Compilation
> worked there. I wonder if this is a toolchain issue or more a barebox
> issue.

I suspect in this case it's barebox.  If you turn on more explicit (verbose)
logging you may see the error in the calls.

--Mark

> I also noticed:
> 
> arm-poky-linux-gnueabi-gcc -dM -E - < /dev/null | grep ARM_PCS
> #define __ARM_PCS 1
> 
> 
>  arm-poky-linux-gnueabi-gcc -mfloat-abi=hard -dM -E - < /dev/null | grep
> ARM_PCS
> #define __ARM_PCS_VFP 1
> 
> Other hf toolchains have __ARM_PCS_VFP 1 regardless if -mfloat-abi
> parameter set or not. I have no clue what the right behaviour should be.
> Can someone explain?
> 
> Regards
> Teresa
> 
> 
> 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ALTERNATIVE_TARGET, ALTERNATIVE_PRIORITY problem

[Mark Hatle]

On 1/28/15 5:12 AM, Joseph Andrew de la Peña wrote:
> Good day Mark,
> 
> Thank you for the response! Really appreciate it. The purpose is the latter as
> what you've provided (three packages that all provide 'bar'. )
> 
> When I tried this one, bar3 is the one pointed by bar. The aim is for bar to
> point bar1 instead. Running rpm -qp as you suggested, they all have same
> priority of 10 w/c made me hypothesize that the result is due to bar3 being 
> the
> last one set as target for bar. Am I correct?
> 
> So my questions:
> 1. Is RPROVIDES not needed anymore when using ALTERNATIVES?

Provide of the specific alternative is automatic with RPM (due to the symlink
stuff).  However, other packaging formats may need it.

If the users are expecting to "Require" 'bar', then an RPROVIDE of 'bar' should
still be done.

> 2. How can I set priority between packages within the same unit/recipe? (so 
> that
> I can reflect bar1 as the one pointed by bar)

For priority:

# The default priority for any alternatives
# ALTERNATIVE_PRIORITY = "priority"
#
#   i.e. default is ALTERNATIVE_PRIORITY = "10"
#
# The non-default priority for a specific target
# ALTERNATIVE_PRIORITY[name] = "priority"
#
# The package priority for a specific target
# ALTERNATIVE_PRIORITY_[name] = "priority"

So you would use:

ALTERNATIVE_PRIORITY_${PN}-bar1[bar] = "100"
ALTERNATIVE_PRIORITY_${PN}-bar2[bar] = "50"
ALTERNATIVE_PRIORITY_${PN}-bar3[bar] = "10"

> 3. When using ALTERNATIVES, is there no need anymore to add the "name" (eg. 
> bar)
> to the packagegroup's RDEPENDS?

You only need to set the rprovide and rdepend in the case were you need a
"required" connection between the provider the user.

In the RPM case, this is often automatic with a file dependency of /bin/bar, but
that can't be represented in the other packaging systems.

So the preference is to state the dependency manually.

What I'm trying to say is "yes" in many cases you will need to do this.
However, keep in mind that the package manager doesn't have any concept of
priority.  And generally only one provider is going to be selected for the 
install..

i.e.

bar1 - RPROVIDE bar
bar2 - RPROVIDE bar
bar3 - RPROVIDE bar

foo - RDEPEND bar

You don't know which of bar1, bar2 or bar3 is actually going to be installed.
If something else in the system can control the install of bar1, bar2 or bar3..
then you can be sure which will be installed AND maintain the dependency.

This often confuses people, but you have to remember that if the dep is 'bar',
that all three meet the definition so the system is free to arbitrarily select
them, even if it's not what you really wanted.

--Mark

> Your response is really really valued!
> 
> Thanks,
> Joseph
> 
> On Wed, Jan 28, 2015 at 12:53 AM, Mark Hatle  > wrote:
> 
> On 1/27/15 9:37 AM, Joseph Andrew de la Peña wrote:
> > Good day Yocto Community,
> >
> > I would like to ask what's wrong with my implementation with 
> update-alternatives:
> 
> I think that you have some of the variables confused below.  I've quoted 
> bits of
> the class's header (internal documentation):
> 
> # List all of the alternatives needed by a package:
> # ALTERNATIVE_ = "name1 name2 name3 ..."
> 
> # The pathname of the link
> # ALTERNATIVE_LINK_NAME[name] = "target"
> 
> # NOTE: If ALTERNATIVE_LINK_NAME is not defined, it defaults to 
> ${bindir}/name
> 
> 
> # The default link to create for all targets
> # ALTERNATIVE_TARGET = "target"
> 
> or
> 
> # A non-default link to create for a target
> # ALTERNATIVE_TARGET[name] = "target"
> 
> # A package specific link for a target
> # ALTERNATIVE_TARGET_[name] = "target"
> #
> #   This is useful when a recipe provides multiple alternatives for the
> #   same item.
> 
> 
> So if you have a single binary called 'bar', and want it to show up as 
> bar1,
> bar2 and bar3 using the alternatives you would do:
> 
> PACKAGES =+ "${PN}-bar1 ${PN}-bar2 ${PN}-bar3"
> ALTERNATIVE_${PN}-bar1 = "bar1"
> ALTERNATIVE_${PN}-bar2 = "bar2"
> ALTERNATIVE_${PN}-bar3 = "bar3"
> 
> ALTERNATIVE_TARGET = "/bin/bar"
> 
> ALTERNATIVE_LINK_NAME[bar1] = "/bin/bar1"
> ALTERNATIVE_LINK_NAME[bar2] = "/bin/bar2"
> ALTERNATIVE_LINK_NAME[bar3] = "/bin/bar3"
> 
> FILES_${PN} = "/bin/bar"
> 
> The result would be:
> 
> package ${PN} contains /bin/bar
> 
> package ${PN}-bar1 would create a link /bin/bar1 -> /bin/bar
> package ${PN}-bar2 would create a link /bin/bar2 -> /bin/bar
> package ${PN}-bar3 would create a link /bin/bar3 -> /bin/bar
> 
> 
> If you want to do the other way around, have three packages that all 
> provide
> 'bar'.  You would do:
> 
> PACKAGES =+ "${PN}-bar1 ${PN}-bar2 ${PN}-bar3"
> ALTERNATIVE_${PN}-bar1 = "bar"
> ALTERNATIVE_${PN}-bar2 = "bar"
> ALTERNATIVE_${PN}-bar3 = "bar"
> 
> ALTERNATIVE_LINK_NAME[bar] = "/bin/bar"
> 
> ALTE

Re: [yocto] MPI support on Yocto

[Alexandru Vaduva]

I would suggest a layer under meta-openembeded: 
meta-openembedded/meta-oe/recipes-devtools/ caould be a start.

Alex Vaduva
 

 On Wednesday, February 4, 2015 12:21 AM, Victor Rodriguez 
 wrote:
   

 On Tue, Feb 3, 2015 at 12:14 PM, Alexandru Vaduva
 wrote:
> I will be more then happy to help you with this.
>
>
> Alex Vaduva
>
>
> On Tuesday, February 3, 2015 5:41 PM, Victor Rodriguez 
> wrote:
>
>
> HI team
>
> I wonder if there is any project or efforts to implement Message
> Passing Interface (MPICH ) support on Yocto ?
>
> If no I am more than happy to work on it , I just will need a little
> bit of guidance
>
> Thanks a lot
>
> Regards
>
> Victor Rodriguez
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>

Thanks Alex

Does anybody knows under which meta - list should we send the patch to review?

Regards

Victor Rodriguez


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Identifying image in os-release

[Moore, Thomas (FtWorth)]

Randy,

Thanks for the tip. Here's what I ended up with:

add_releaseinfo () {
sed -i "/NAME=/s/${DISTRO_NAME}/${DISTRO_NAME} (Debug)/" 
${IMAGE_ROOTFS}/${sysconfdir}/os-release
}

ROOTFS_POSTPROCESS_COMMAND += " add_releaseinfo ; "

Thomas 


-Original Message-
From: Randy Witt [mailto:randy.e.w...@linux.intel.com] 
Sent: Tuesday, February 03, 2015 2:49 PM
To: Moore, Thomas (FtWorth); yocto@yoctoproject.org
Subject: Re: [yocto] Identifying image in os-release

On 02/03/2015 11:42 AM, Moore, Thomas (FtWorth) wrote:
> For my system, we are generating two images: a release image and a debug 
> image. The debug image simply adds the debug image features (tools-debug, 
> eclipse-debug, and dbg-pkgs). This approach looks like it is going to work 
> well for our needs. However, the one issue that I have is that there doesn't 
> appear to be a way to easily tell which image is running. My current plan for 
> version identification is to make use of the /etc/os-release file that is 
> generated during the build, which is suitable for determining the version of 
> the base distribution. However, I can't find a way to influence any of those 
> values from within my image recipes, which I image is by design.
>
> It would seem to me that having a way to assign a version, or some other 
> identifying information, to a final image would be very important. The 
> DISTRO_VERSION is nice, but it doesn't seem like it's enough considering that 
> you can write an image recipe to add any number of additional packages.
>
> Any suggestions on how I can achieve this?

If you are willing to use a file other than os-release, I've often seen this 
done using a function in ROOTFS_POSTPROCESS_COMMAND 
https://www.yoctoproject.org/docs/1.7/ref-manual/ref-manual.html#var-ROOTFS_POSTPROCESS_COMMAND.
 
For example:

add_releaseinfo () {
 echo "foo: ${FOOVAR}" > ${IMAGE_ROOTFS}/${sysconfdir}/somefile
 echo "bar: ${BARVAR}" >> ${IMAGE_ROOTFS}/${sysconfdir}/somefile
}

ROOTFS_POSTPROCESS_COMMAND += " add_releaseinfo ; "
> Thanks,
>
> Thomas
>
>

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] MPI support on Yocto

[Victor Rodriguez]

On Tue, Feb 3, 2015 at 12:14 PM, Alexandru Vaduva
 wrote:
> I will be more then happy to help you with this.
>
>
> Alex Vaduva
>
>
> On Tuesday, February 3, 2015 5:41 PM, Victor Rodriguez 
> wrote:
>
>
> HI team
>
> I wonder if there is any project or efforts to implement Message
> Passing Interface (MPICH ) support on Yocto ?
>
> If no I am more than happy to work on it , I just will need a little
> bit of guidance
>
> Thanks a lot
>
> Regards
>
> Victor Rodriguez
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>

Thanks Alex

Does anybody knows under which meta - list should we send the patch to review?

Regards

Victor Rodriguez
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ACPI powerbtn

[Burton, Ross]

On 3 February 2015 at 21:30, Jim Abernathy  wrote:

> I need to add something that will 'shutdown -h now' when the power button
> is pressed.  I would figure that ACPI is already included in the
> core-image-base of the NUC bsp.
>
> Do I need to include a new file in /etc/acpi/events or do I need to
> include some package?
>

I'm literally signing off for the day but for what it's worth
core-image-sato does that already on my NUC, so there must be something in
that image that makes it work...  maybe acpid or acpi-support isn't part of
core-image-base?

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] ACPI powerbtn

[Jim Abernathy]

I need to add something that will 'shutdown -h now' when the power button is 
pressed.  I would figure that ACPI is already included in the core-image-base 
of the NUC bsp.

Do I need to include a new file in /etc/acpi/events or do I need to include 
some package?

Jim A

  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Identifying image in os-release

[Randy Witt]

On 02/03/2015 11:42 AM, Moore, Thomas (FtWorth) wrote:

For my system, we are generating two images: a release image and a debug image. 
The debug image simply adds the debug image features (tools-debug, 
eclipse-debug, and dbg-pkgs). This approach looks like it is going to work well 
for our needs. However, the one issue that I have is that there doesn't appear 
to be a way to easily tell which image is running. My current plan for version 
identification is to make use of the /etc/os-release file that is generated 
during the build, which is suitable for determining the version of the base 
distribution. However, I can't find a way to influence any of those values from 
within my image recipes, which I image is by design.

It would seem to me that having a way to assign a version, or some other 
identifying information, to a final image would be very important. The 
DISTRO_VERSION is nice, but it doesn't seem like it's enough considering that 
you can write an image recipe to add any number of additional packages.

Any suggestions on how I can achieve this?


If you are willing to use a file other than os-release, I've often seen this 
done using a function in ROOTFS_POSTPROCESS_COMMAND 
https://www.yoctoproject.org/docs/1.7/ref-manual/ref-manual.html#var-ROOTFS_POSTPROCESS_COMMAND. 
For example:


add_releaseinfo () {
echo "foo: ${FOOVAR}" > ${IMAGE_ROOTFS}/${sysconfdir}/somefile
echo "bar: ${BARVAR}" >> ${IMAGE_ROOTFS}/${sysconfdir}/somefile
}

ROOTFS_POSTPROCESS_COMMAND += " add_releaseinfo ; "

Thanks,

Thomas




--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] patch_do_patch error for local kernel rep..,

[Pavan Kumar B]

Hi,

I was trying to set the local repo for kernel and build the yocto image.
For that

I have set SRC_URI as below located at $
/fsl-community-bsp/sources/meta-fsl-arm-extra/recipes-kernel/linux/linux-wandboard.inc

SRC_URI = "git:///home/jos/test/temp/mykernel;protocol=file;bareclone=1"

and it started recognizing the local repo..,

Also I have modified the linux-imx file "S" parameter as below

S = "/home/jos/test/temp/mykernel"

But I ran into another error and log is mentioned below

The kernel baseline in my local repo is 3.0.35-4.1.0 and the I am using
dora yocto branch

There are some set of patches I can see at linux-imx_3.0.35.bb as below

# GPU support patches
SRC_URI += "file://drm-vivante-Add-00-sufix-in-returned-bus-Id.patch \

file://0001-ENGR00255688-4.6.9p11.1-gpu-GPU-Kernel-driver-integr.patch \

file://0002-ENGR00265465-gpu-Add-global-value-for-minimum-3D-clo.patch \

file://0003-ENGR00261814-4-gpu-use-new-PU-power-on-off-interface.patch \

file://0004-ENGR00264288-1-GPU-Integrate-4.6.9p12-release-kernel.patch \

file://0005-ENGR00264275-GPU-Correct-suspend-resume-calling-afte.patch \

file://0006-ENGR00265130-gpu-Correct-section-mismatch-in-gpu-ker.patch"


The patch function is failing here. But with the kernel that was downloaded
from git previously for wandboard is compiling with same patches with out
any problem. These patches don't work for 3.0.35-4.1.0?

What should be done here to apply patch & compile the image.

please do guide me over here

Regards,
Pavan

PS: Attached is the error log file
Loading cache: 100% 
|#|
 ETA:  00:00:00
Loaded 1737 entries from dependency cache.
Parsing recipes: 100% 
|###|
 Time: 00:00:00
Parsing of 1343 .bb files complete (1342 cached, 1 parsed). 1736 targets, 78 
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION= "1.20.0"
BUILD_SYS = "i686-linux"
NATIVELSBSTRING   = "Ubuntu-12.04"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "wandboard-quad"
DISTRO= "poky"
DISTRO_VERSION= "1.5.4"
TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa9"
TARGET_FPU= "vfp-neon"
meta  
meta-yocto= "(nobranch):e035c59d7d331ddaeff19b069169567af5e6f8ac"
meta-oe   = "(nobranch):e75ae8f50af3effe560c43fc63cfd1f39395f011"
meta-fsl-arm  = "(nobranch):5fdb620c09df11e70434092f675c891e0ba84108"
meta-fsl-arm-extra = "(nobranch):375f89b70655be2a17bbde36de6adb4e4a5a6975"
meta-fsl-demos= "(nobranch):5a12677ad000a926d23c444266722a778ea228a7"

NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Command Error: exit status: 1  Output:
Applying patch drm-vivante-Add-00-sufix-in-returned-bus-Id.patch
patching file drivers/gpu/drm/vivante/vivante_drv.c
Hunk #1 FAILED at 55.
1 out of 1 hunk FAILED -- rejects in file drivers/gpu/drm/vivante/vivante_drv.c
Patch drm-vivante-Add-00-sufix-in-returned-bus-Id.patch can be reverse-applied
ERROR: Function failed: patch_do_patch
ERROR: Logfile of failure stored in: 
/home/jos/Desktop/work/yocto/fsl-community-bsp/build/tmp/work/wandboard_quad-poky-linux-gnueabi/linux-wandboard/3.0.35-r0/temp/log.do_patch.8012
ERROR: Task 82 
(/home/jos/Desktop/work/yocto/fsl-community-bsp/sources/meta-fsl-arm-extra/recipes-kernel/linux/linux-wandboard_3.0.35.bb,
 do_patch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1554 tasks of which 1551 didn't need to be rerun 
and 1 failed.
No currently running tasks (1554 of 1581)

Summary: 1 task failed:
  
/home/jos/Desktop/work/yocto/fsl-community-bsp/sources/meta-fsl-arm-extra/recipes-kernel/linux/linux-wandboard_3.0.35.bb,
 do_patch
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Identifying image in os-release

[Moore, Thomas (FtWorth)]

For my system, we are generating two images: a release image and a debug image. 
The debug image simply adds the debug image features (tools-debug, 
eclipse-debug, and dbg-pkgs). This approach looks like it is going to work well 
for our needs. However, the one issue that I have is that there doesn't appear 
to be a way to easily tell which image is running. My current plan for version 
identification is to make use of the /etc/os-release file that is generated 
during the build, which is suitable for determining the version of the base 
distribution. However, I can't find a way to influence any of those values from 
within my image recipes, which I image is by design.

It would seem to me that having a way to assign a version, or some other 
identifying information, to a final image would be very important. The 
DISTRO_VERSION is nice, but it doesn't seem like it's enough considering that 
you can write an image recipe to add any number of additional packages.

Any suggestions on how I can achieve this?

Thanks,

Thomas 


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] DNS nameservers in Yocto

[Dean]

On 2/3/2015 12:11 PM, Paul Eggleton wrote:

Hi Dean,

On Tuesday 03 February 2015 11:20:01 Dean wrote:

On 2/3/2015 9:43 AM, Jim Abernathy wrote:

I find that for Static IPs, I have to manually add my DNS name servers
to /etc/resolv.conf instead of what I'm use to and that's put the line
in /etc/network/interfaces with the dns-nameserver [IP] [IP].

My knowledge base comes from Ubuntu Server where putting everything in
"/etc/network/interfaces" covers most things.

Anyone know why?

Add resolvconf to your image.

That being said, I'm using dora and the package there was very
incomplete. I had to add quite a bit in a .bbappend to make it work
properly.

Would the issues you found have been fixed by this commit?

   
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=35e0a3eb6725781eb291b3fa90694a68c3b64c60

If not, we should really try to get these fixed in the original recipe - we'd
certainly appreciate help there.

Cheers,
Paul



Yeah, that's about 95% of it. I don't think it has a service yet though?

Here is my .bbappend. It probably isn't perfect or bug free, but working 
on my dora builds. I think I ripped the scripts out of the debian 
packages and then fixed anything necessary to make them work with busybox.


cat resolvconf_1.74.bbappend
# Added by Dean to fix issues in resolvconf recipe

# look for files in this layer first
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI += " file://fixpath.patch \
 file://resolvconf.init \
 file://netresolvconfdown \
 file://netresolvconfup \
 file://pppresolvconfdown \
 file://pppresolvconfup "

inherit update-rc.d

INITSCRIPT_NAME = "resolvconf"
INITSCRIPT_PARAMS = "start 39 S . stop 41 0 6 ."

# add list-records script, its missing in distro
# add volatile resolv.conf - package maintainer didnt??!@?!
# Add startup/shutdown script
FILES_${PN} += " /lib/resolvconf/list-records "
do_install_append () {
install -d ${D}/lib/${BPN}
install -m 0755 bin/list-records ${D}/lib/${BPN}/

echo "l root root 0644 /etc/resolv.conf 
${sysconfdir}/${BPN}/run/resolv.conf" >> 
${D}${sysconfdir}/default/volatiles/99_resolvconf
echo "f root root 0644 ${sysconfdir}/${BPN}/run/resolv.conf none" 
  >> ${D}${sysconfdir}/default/volatiles/99_resolvconf


install -d ${D}${sysconfdir}/init.d
cp ${WORKDIR}/resolvconf.init ${WORKDIR}/resolvconf
install -m 0755 ${WORKDIR}/resolvconf ${D}${sysconfdir}/init.d/

# Add things needed for interfaces coming up and down
install -d ${D}${sysconfdir}/network/if-down.d/
install -d ${D}${sysconfdir}/network/if-up.d/
install -d ${D}${sysconfdir}/ppp/ip-down.d/
install -d ${D}${sysconfdir}/ppp/ip-up.d/
install -m 0755 ${WORKDIR}/netresolvconfdown 
${D}${sysconfdir}/network/if-down.d/resolvconf
install -m 0755 ${WORKDIR}/netresolvconfup 
${D}${sysconfdir}/network/if-up.d/000resolvconf
install -m 0755 ${WORKDIR}/pppresolvconfdown 
${D}${sysconfdir}/ppp/ip-down.d/000resolvconf
install -m 0755 ${WORKDIR}/pppresolvconfup 
${D}${sysconfdir}/ppp/ip-up.d/000resolvconf


}
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] DNS nameservers in Yocto

[Jim Abernathy]

> From: paul.eggle...@linux.intel.com
> To: d...@ripperd.com
> CC: jfaberna...@outlook.com; yocto@yoctoproject.org
> Subject: Re: [yocto] DNS nameservers in Yocto
> Date: Tue, 3 Feb 2015 18:11:12 +
> 
> Hi Dean,
> 
> On Tuesday 03 February 2015 11:20:01 Dean wrote:
> > On 2/3/2015 9:43 AM, Jim Abernathy wrote:
> > > I find that for Static IPs, I have to manually add my DNS name servers
> > > to /etc/resolv.conf instead of what I'm use to and that's put the line
> > > in /etc/network/interfaces with the dns-nameserver [IP] [IP].
> > > 
> > > My knowledge base comes from Ubuntu Server where putting everything in
> > > "/etc/network/interfaces" covers most things.
> > > 
> > > Anyone know why?
> >
> > Add resolvconf to your image.
> > 
> > That being said, I'm using dora and the package there was very
> > incomplete. I had to add quite a bit in a .bbappend to make it work
> > properly.
> 
> Would the issues you found have been fixed by this commit?
> 
>   
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=35e0a3eb6725781eb291b3fa90694a68c3b64c60
> 
> If not, we should really try to get these fixed in the original recipe - we'd 
> certainly appreciate help there.
> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre

Just adding 'resolvconf' fixed my issue on dizzy.

Jim A

  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] MPI support on Yocto

[Alexandru Vaduva]

I will be more then happy to help you with this.

Alex Vaduva
 

 On Tuesday, February 3, 2015 5:41 PM, Victor Rodriguez 
 wrote:
   

 HI team

I wonder if there is any project or efforts to implement Message
Passing Interface (MPICH ) support on Yocto ?

If no I am more than happy to work on it , I just will need a little
bit of guidance

Thanks a lot

Regards

Victor Rodriguez
-- 
___
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] DNS nameservers in Yocto

[Paul Eggleton]

Hi Dean,

On Tuesday 03 February 2015 11:20:01 Dean wrote:
> On 2/3/2015 9:43 AM, Jim Abernathy wrote:
> > I find that for Static IPs, I have to manually add my DNS name servers
> > to /etc/resolv.conf instead of what I'm use to and that's put the line
> > in /etc/network/interfaces with the dns-nameserver [IP] [IP].
> > 
> > My knowledge base comes from Ubuntu Server where putting everything in
> > "/etc/network/interfaces" covers most things.
> > 
> > Anyone know why?
>
> Add resolvconf to your image.
> 
> That being said, I'm using dora and the package there was very
> incomplete. I had to add quite a bit in a .bbappend to make it work
> properly.

Would the issues you found have been fixed by this commit?

  
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=35e0a3eb6725781eb291b3fa90694a68c3b64c60

If not, we should really try to get these fixed in the original recipe - we'd 
certainly appreciate help there.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] DNS nameservers in Yocto

[Dean]

Add resolvconf to your image.

That being said, I'm using dora and the package there was very 
incomplete. I had to add quite a bit in a .bbappend to make it work 
properly.



On 2/3/2015 9:43 AM, Jim Abernathy wrote:
I find that for Static IPs, I have to manually add my DNS name servers 
to /etc/resolv.conf instead of what I'm use to and that's put the line 
in /etc/network/interfaces with the dns-nameserver [IP] [IP].


My knowledge base comes from Ubuntu Server where putting everything in 
"/etc/network/interfaces" covers most things.


Anyone know why?

Jim A





-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding 'sbin' to default path

[Ash Charles]

Hi Paul,

Thanks very much for the explanation!  I'm coming from an Ubuntu world
where it seems they didn't follow Debian's lead in this case ;-).

As this does seem to be distro-dependent, I'll maintain my patch as
being a reasonable workaround and now understand why meta uses
non-sbin path.

Cheers,
Ash

On Tue, Feb 3, 2015 at 2:40 AM, Paul Eggleton
 wrote:
> Hi Ash,
>
> On Friday 30 January 2015 10:28:21 Ash Charles wrote:
>> Why does the PATH variable in the dot.bashrc shipped by the base-files
>> not include 'sbin' paths?  It seems like any interactive user should
>> be able to call e.g. 'ifconfig' informationally---they should, and
>> would still be, blocked from calling 'ifconfig eth0 up'
>>
>> After looking at the PATH for a generic user on my local Ubuntu
>> system, I just added a patch to my meta layer to add the following
>> line to the dot.bashrc:
>>
>> export PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin
>>
>> It seems to work well---users created with the extrauser class pull
>> this default from the skel.
>>
>> As this is security related though, I wanted to ask the question to
>> make sure I'm not doing something silly, dangerous or otherwise
>> idiotic.
>
> I think this is largely a distro decision - some distros include the sbin
> directories to PATH for all users (e.g. Fedora), others reserve that for root
> only (e.g. Debian) on the assumption that everything in /sbin and /usr/sbin is
> intended for administration rather than normal users. I guess we are just
> picking up the default from base-files which comes from Debian.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi][ANNOUNCEMENT] Official issue tracker

[Andrei Gherzan]

Hello rPIans,

Following your feedback, we now have a new tool for tracking the issues
related to meta-raspberrypi BSP yocto layer (
http://redmine.gherzan.ro/projects/meta-raspberrypi). An issue might be a
bug, a feature or a support ticket. This redmine server will replace any
other tools that we used (Trello, github etc) and will be the only official
way to report and trace issues. This tool will NOT replace the discussions
on the mailing list. For more information read the updated README file.

Quick links
===
Git repository web frontend:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/
Mailing list (yocto mailing list):
yocto@yoctoproject.org

*Issues management (redmine):*
*http://redmine.gherzan.ro/projects/meta-raspberrypi
*
Change review (gerrit):
https://review.gherzan.ro:8443/#/q/project:meta-raspberrypi


Happy hacking!

-- 
*Andrei Gherzan*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] DNS nameservers in Yocto

[Jim Abernathy]

I find that for Static IPs, I have to manually add my DNS name servers to 
/etc/resolv.conf instead of what I'm use to and that's put the line in 
/etc/network/interfaces with the dns-nameserver [IP] [IP].

My knowledge base comes from Ubuntu Server where putting everything in 
"/etc/network/interfaces" covers most things.

Anyone know why?

Jim A

  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] MPI support on Yocto

[Victor Rodriguez]

HI team

I wonder if there is any project or efforts to implement Message
Passing Interface (MPICH ) support on Yocto ?

If no I am more than happy to work on it , I just will need a little
bit of guidance

Thanks a lot

Regards

Victor Rodriguez
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto-custom-kernel issue

[Bruce Ashfield]

On 15-02-03 07:40 AM, Raghavendra Kakarla wrote:

Hi,
  I want to add BSP layer for my mechine and I should take the our own 
customized kernel source(our kernel source).

  For that I add the BSP layer and wrote the recipe for that.

  My recipe is as follows:

***

  # This file was derived from the linux-yocto-custom.bb recipe in
# oe-core.
#
# linux-yocto-custom.bb:
#
#   A yocto-bsp-generated kernel recipe that uses the linux-yocto and
#   oe-core kernel classes to apply a subset of yocto kernel
#   management to git managed kernel repositories.
#
# Warning:
#
#   Building this kernel without providing a defconfig or BSP
#   configuration will result in build or boot errors. This is not a
#   bug.
#
# Notes:
#
#   patches: patches can be merged into to the source git tree itself,
#added via the SRC_URI, or controlled via a BSP
#configuration.
#
#   example configuration addition:
#SRC_URI += "file://smp.cfg"
#   example patch addition:
#SRC_URI += 
"file://0/home/testuser/yocto.git/android-linux-mti-unif-3.10.14/arch/mips/configs001-linux-version-tweak.patch
#   example feature addition:
#SRC_URI += "file://feature.scc"
#
inherit kernel
require recipes-kernel/linux/linux-yocto.inc

SRC_URI = 
"git://192.168.42.75/vineethchowdhary/incdhad1-kernel-3-10.git;protocol=http;bareclone=1"

SRC_URI += "file://defconfig"

SRC_URI += "file://mydhanush.scc \
 file://mydhanush.cfg \
 file://mydhanush-user-config.cfg \
 file://mydhanush-user-patches.scc \
"


LINUX_VERSION ?= "3.10.14"
LINUX_VERSION_EXTENSION ?= "-custom"

#SRCREV="12bbf6468e2ef179800aaab46c724f523b5002e3"
SRCREV="f91e563c45d457aa441f687eda294ad899e2b25f"
PR = "r0"
PV = "${LINUX_VERSION}+git${SRCPV}"

#COMPATIBLE_MACHINE_mydhanush = "mydhanush"
COMPATIBLE_MACHINE_mydhanush = "mydhanush"

***


but I got error as follows:

Log data follows:
| DEBUG: Executing shell function do_kernel_checkout
| ERROR: S is not set to the linux source directory. Check
| ERROR: the recipe and set S to the proper extracted subdirectory
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_kernel_checkout (log file is located at 
/home/testuser/poky/build/tmp/work/mydhanush-poky-linux/linux-yocto-custom/3.10.14+gitAUTOINC+f91e563c45-r0/temp/log.do_kernel_checkout.11798)

could you please help for resolving this issue.


And if dump the bitbake environment for your kernel build, what is S
set to ? And when you go to that same directory on your build machine,
what do you see ?

The checkout code is telling you that it doesn't see a Makefile in
the source directory, so where ever it is pointing isn't valid.

Cheers,

Bruce



Thanks and Regards,

Raghavendra.



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto-custom-kernel issue

[Sven Ebenfeld]

Hi Raghavendra,

Am 03.02.2015 um 13:40 schrieb Raghavendra Kakarla:
> Hi,
>  I want to add BSP layer for my mechine and I should take the our own 
> customized kernel source(our kernel source).
> 
>  For that I add the BSP layer and wrote the recipe for that.
> 
>  My recipe is as follows:
> 
> ***
> 
>  # This file was derived from the linux-yocto-custom.bb recipe in
> # oe-core.
> #
> # linux-yocto-custom.bb:
> #
> #   A yocto-bsp-generated kernel recipe that uses the linux-yocto and
> #   oe-core kernel classes to apply a subset of yocto kernel
> #   management to git managed kernel repositories.
> #
> # Warning:
> #
> #   Building this kernel without providing a defconfig or BSP
> #   configuration will result in build or boot errors. This is not a
> #   bug.
> #
> # Notes:
> #
> #   patches: patches can be merged into to the source git tree itself,
> #added via the SRC_URI, or controlled via a BSP
> #configuration.
> #
> #   example configuration addition:
> #SRC_URI += "file://smp.cfg"
> #   example patch addition:
> #SRC_URI += 
> "file://0/home/testuser/yocto.git/android-linux-mti-unif-3.10.14/arch/mips/configs001-linux-version-tweak.patch
> #   example feature addition:
> #SRC_URI += "file://feature.scc"
> #
> inherit kernel
> require recipes-kernel/linux/linux-yocto.inc
> 
> SRC_URI = 
> "git://192.168.42.75/vineethchowdhary/incdhad1-kernel-3-10.git;protocol=http;bareclone=1"

Why are you doing a bareclone??
Shouldn't it do a checkout to have a working copy that it can compile?

> 
> SRC_URI += "file://defconfig"
> 
> SRC_URI += "file://mydhanush.scc \
> file://mydhanush.cfg \
> file://mydhanush-user-config.cfg \
> file://mydhanush-user-patches.scc \
>"
> 
> 
> LINUX_VERSION ?= "3.10.14"
> LINUX_VERSION_EXTENSION ?= "-custom"
> 
> #SRCREV="12bbf6468e2ef179800aaab46c724f523b5002e3"
> SRCREV="f91e563c45d457aa441f687eda294ad899e2b25f"
> PR = "r0"
> PV = "${LINUX_VERSION}+git${SRCPV}"
> 
> #COMPATIBLE_MACHINE_mydhanush = "mydhanush"
> COMPATIBLE_MACHINE_mydhanush = "mydhanush"
> 
> ***
> 
> 
> but I got error as follows:
> 
> Log data follows:
> | DEBUG: Executing shell function do_kernel_checkout
> | ERROR: S is not set to the linux source directory. Check
> | ERROR: the recipe and set S to the proper extracted subdirectory

This states, that it doesn't find the source directory where it is
expected. If "bareclone=1" has the effect I think it has, this is normal
as there will probably only be a bare git repository insted of it's
working copy.

> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_kernel_checkout (log file is located at 
> /home/testuser/poky/build/tmp/work/mydhanush-poky-linux/linux-yocto-custom/3.10.14+gitAUTOINC+f91e563c45-r0/temp/log.do_kernel_checkout.11798)
> 
> could you please help for resolving this issue.
> 
> Thanks and Regards,
> 
> Raghavendra.
> 

Cheers,
Sven
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] yocto-custom-kernel issue

[Raghavendra Kakarla]

Hi,
 I want to add BSP layer for my mechine and I should take the our own 
customized kernel source(our kernel source).

 For that I add the BSP layer and wrote the recipe for that.

 My recipe is as follows:

***

 # This file was derived from the linux-yocto-custom.bb recipe in
# oe-core.
#
# linux-yocto-custom.bb:
#
#   A yocto-bsp-generated kernel recipe that uses the linux-yocto and
#   oe-core kernel classes to apply a subset of yocto kernel
#   management to git managed kernel repositories.
#
# Warning:
#
#   Building this kernel without providing a defconfig or BSP
#   configuration will result in build or boot errors. This is not a
#   bug.
#
# Notes:
#
#   patches: patches can be merged into to the source git tree itself,
#added via the SRC_URI, or controlled via a BSP
#configuration.
#
#   example configuration addition:
#SRC_URI += "file://smp.cfg"
#   example patch addition:
#SRC_URI += 
"file://0/home/testuser/yocto.git/android-linux-mti-unif-3.10.14/arch/mips/configs001-linux-version-tweak.patch
#   example feature addition:
#SRC_URI += "file://feature.scc"
#
inherit kernel
require recipes-kernel/linux/linux-yocto.inc

SRC_URI = 
"git://192.168.42.75/vineethchowdhary/incdhad1-kernel-3-10.git;protocol=http;bareclone=1"

SRC_URI += "file://defconfig"

SRC_URI += "file://mydhanush.scc \
file://mydhanush.cfg \
file://mydhanush-user-config.cfg \
file://mydhanush-user-patches.scc \
   "


LINUX_VERSION ?= "3.10.14"
LINUX_VERSION_EXTENSION ?= "-custom"

#SRCREV="12bbf6468e2ef179800aaab46c724f523b5002e3"
SRCREV="f91e563c45d457aa441f687eda294ad899e2b25f"
PR = "r0"
PV = "${LINUX_VERSION}+git${SRCPV}"

#COMPATIBLE_MACHINE_mydhanush = "mydhanush"
COMPATIBLE_MACHINE_mydhanush = "mydhanush"

***


but I got error as follows:

Log data follows:
| DEBUG: Executing shell function do_kernel_checkout
| ERROR: S is not set to the linux source directory. Check
| ERROR: the recipe and set S to the proper extracted subdirectory
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_kernel_checkout (log file is located at 
/home/testuser/poky/build/tmp/work/mydhanush-poky-linux/linux-yocto-custom/3.10.14+gitAUTOINC+f91e563c45-r0/temp/log.do_kernel_checkout.11798)

could you please help for resolving this issue.

Thanks and Regards,

Raghavendra.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [RFC]provide native recipe for every package

[Burton, Ross]

On 3 February 2015 at 09:55, Paul Eggleton 
wrote:

> Assuming what you mean is BBCLASSEXTEND = "native" for every recipe, I
> don't
> think we want to do this. There are a lot of things that should simply be
> provided by the host rather than us building them; we need to be selective
> about what we build as a workaround for the host not providing a suitable
> version.
>

Also, simply adding BBCLASSEXTEND="native" doesn't magically work all the
time. Options may need to be changed, dependencies altered, and so on.  By
making this opt-in someone has to test that it actually works.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

On 3 February 2015 at 05:03, Khem Raj  wrote:

> I think this issue was there even with older version of glibc for i7
> but it was flagged as a warning, glibc 2.21 now uses -Werror by
> default. Can you confirm that via inspecting 2.20 glibc build logs for
> this machine ?
>

dl-caller.c:1:0: warning: SSE instruction set disabled, using 387
arithmetics
 /* Check whether caller comes from the right place.
 ^
../sysdeps/unix/sysv/linux/dl-execstack.c:1:0: warning: SSE instruction set
disabled, using 387 arithmetics
 /* Stack executability handling for GNU dynamic linker.  Linux version.
 ^

You're right.  I'll test the new branch shortly.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding 'sbin' to default path

[Paul Eggleton]

Hi Ash,

On Friday 30 January 2015 10:28:21 Ash Charles wrote:
> Why does the PATH variable in the dot.bashrc shipped by the base-files
> not include 'sbin' paths?  It seems like any interactive user should
> be able to call e.g. 'ifconfig' informationally---they should, and
> would still be, blocked from calling 'ifconfig eth0 up'
> 
> After looking at the PATH for a generic user on my local Ubuntu
> system, I just added a patch to my meta layer to add the following
> line to the dot.bashrc:
> 
> export PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin
> 
> It seems to work well---users created with the extrauser class pull
> this default from the skel.
> 
> As this is security related though, I wanted to ask the question to
> make sure I'm not doing something silly, dangerous or otherwise
> idiotic.

I think this is largely a distro decision - some distros include the sbin 
directories to PATH for all users (e.g. Fedora), others reserve that for root 
only (e.g. Debian) on the assumption that everything in /sbin and /usr/sbin is 
intended for administration rather than normal users. I guess we are just 
picking up the default from base-files which comes from Debian.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Unset task_name[noexec] in bbappend

[Paul Eggleton]

Hi Paul,

On Monday 02 February 2015 19:51:15 Stath, Paul wrote:
> If there any way in the bbappend file to override [noexec] = "1"
> specified in the parent .bb file?
> 
> I want to extend the package-index task, and need to fetch a couple of
> configuration files. The package-index.bb task contains do_fetch[noexec] =
> "1", so the fetch is not performed.

This is a little tricky - you need to actually delete the varflag not just 
unset it. (You'll almost certainly need to do the same for do_unpack so that 
the files end up in the workdir as well.) You can do this from an anonymous 
python section within the recipe e.g.:

python __anonymous() {
d.delVarFlag('do_fetch', 'noexec')
d.delVarFlag('do_unpack', 'noexec')
}

(I'm not sure what you're doing this for, but in case it's not obvious, bear 
mind this will only affect explicit calls to bitbake package-index and won't be 
automatically incorporated into the indexes created when building images.)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [RFC]provide native recipe for every package

[Paul Eggleton]

Hi Bian,

On Tuesday 03 February 2015 00:38:54 Bian, Naimeng wrote:
> Would you tell me why can't we inherit native.bbclass in every recipes.
> IMO, it's better to provide native recipe for every package.

Assuming what you mean is BBCLASSEXTEND = "native" for every recipe, I don't 
think we want to do this. There are a lot of things that should simply be 
provided by the host rather than us building them; we need to be selective 
about what we build as a workaround for the host not providing a suitable 
version.

See this bug for an example of at least one way this can go wrong:

  https://bugzilla.yoctoproject.org/show_bug.cgi?id=7264

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] bitbake-whatchanged error

[Paul Eggleton]

On Tuesday 03 February 2015 09:53:30 ChenQi wrote:
> On 02/03/2015 02:40 AM, Paul Eggleton wrote:
> > On Monday 02 February 2015 09:33:30 Gary Thomas wrote:
> >> Every time I run the 'bitbake-whatchanged' script, I get an
> >> 
> >> error like this:
> >> ERROR: Bitbake's cached basehash does not match the one we just
> >> generated
> >> 
> >> (/home/local/poky-cutting-edge/meta-imx6/packages/images/imx6-demo-image.
> >> bb
> >> .do_rootfs)! ERROR: The mismatched hashes were
> >> e48dfde9772b0a567b5327087c9e2d44 and 3c3447f08ef4da61b814bff5fb909bff
> >> 
> >> What causes this and should I be worried?  Does it affect
> >> the actual results which are shown?
> > 
> > I don't think you should necessarily be worried, but this is definitely a
> > bug and we should fix it. It affects bitbake -S printdiff as well. If you
> > have a chance it would be great if you could file a bug about it.
> > 
> > Thanks,
> > Paul
> 
> I've sent a patch to OE-core mailing list to fix this problem.
> The title is:
> image.bbclass: don't let do_rootfs depend on BUILDNAME

Great. Thank you!

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to use different busybox defconfig's in the initramfs and rootfs image

[Erwin . Rieger . ext]

Hello,

thank you for your reply.

I have a working solution now, but it is not as clean as i would like it to be 
and some new questions arose with it.

My current setup consists of a busybox.bbappend file that is used to customize 
the rootfs
busybox (defconfig, some /etc files and so on) and a busybox-initramfs.bb 
recipe for the initramfs busybox (as you
suggested).

The busybox.bbappend (see below) is straight forward, so no problem with that.

To create the busybox-initramfs.bb in my custom layer, i have included the base 
busybox recipe from the meta layer with
an 'require' statement.

Then i had to extend the FILESEXTRAPATHS variable to point back to the base 
recipe files-directory since it
no longer found the SRC_URI files from meta/busybox.bb and meta/busybox.inc. 
See the BUSYBOXBASEDIR
variable in the busybox-initramfs.bb below.

I feel that his construct is not that elegant, so here comes the first question:

Is there a nicer/cleaner way to include/reference the source files from the 
base busybox recipe in the meta layer?

The second question concerns the versioning: The busybox.bbappend file uses a 
'version wildcard' (_%) to
match all versions of the base busybox recipe. But in the busybox-initramfs.bb 
recipe i have to hardwire the 
version of the base recipe.

How can i use a 'version wildcard' in a 'require' statement?

I've tried 'require recipes-core/busybox/busybox_%.bb' but that gives me a 
parse error so it seems not to be
possible to use version wildcards together with require/include.


My current busybox-initramfs.bb recipe:
---
DESCRIPTION = "Use different busybox defconfig for initramfs."

# require recipes-core/busybox/busybox_1.22.1.bb

PV = "1.22.1"
require recipes-core/busybox/busybox_${PV}.bb

S = "${WORKDIR}/busybox-${PV}"

# Point FILESPATH to base busybox files dir
BUSYBOXBASEDIR = "${THISDIR}/../../../meta/recipes-core/busybox"
FILESEXTRAPATHS_prepend := "${BUSYBOXBASEDIR}/busybox:"
FILESEXTRAPATHS_prepend := "${BUSYBOXBASEDIR}/files:"

# Include our initramfs busybox defconfig
FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"

BUSYBOX_SPLIT_SUID = "0"
---


The busybox_%.bbappend for the rootfs busybox:
---
DESCRIPTION = "Customize busybox."

# Include our rootfs busybox defconfig 
FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"

SRC_URI += " \
    file://inetd.conf \
    "

do_install_append() {
    install ${WORKDIR}/inetd.conf ${D}${sysconfdir}
}

BUSYBOX_SPLIT_SUID = "0"
---

Best Regards, Erwin Rieger



-ChenQi  schrieb: -
An: , 
Von: ChenQi 
Datum: 03.02.2015 02:48
Betreff: Re: [yocto] How to use different busybox defconfig's in the initramfs 
and rootfs image

The only way I know is to make a new recipe, busybox-initramfs.bb, for example.
Install busybox for image rootfs and busybox-initramfs for initramfs.

Best Regards,
Chen Qi

On 02/02/2015 09:21 PM, erwin.rieger@rohde-schwarz.com wrote:
Hello list,

i have used Yocto to create a initramfs linux kernel and a corresponding rootfs 
for a embedded linux system.

Things are working as expected, so far.

Now i want to fine-tune my setup and want to use a different busybox 
configuration in the initramfs as the one in the rootfs image.
For example, the initramfs busybox should contain support for switch-root and 
that is not needed in the rootfs.
On the other hand, the rootfs should contain a "full-fledged" busybox (with 
inetd enabled, for example).

So the question is: How can i build/install a package two times with differing 
configurations in one bitbake run?.

How can this be done the Yocto-way without copying busybox.bb and hacking it 
the way i need it?

I've tried various combinations, e.g. bb-appending busybox, inheriting from 
busybox and so on - but to no avail.

Maybe someone have an idea on how to do that?


PS:
* The kernel recipe is derived (bbappend) from core-image-minimal-initramfs.
* Rootfs recipe is derived from core-image-minimal.bb.


-- 
Erwin Rieger
-- 



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto