[yocto] Getting a recipe's files from within an image recipe

[colin.helliwell]

I have an app which has a config file, and I'd like my two images
(production and dev) to have different configs. Obviously it'd be neater to
keep the two config files within the recipe's directory structure.
I guess I can't do this in the app's recipe since it has no concept of what
image it might end up in. So I could have the the app's recipe deploy one of
the configs by default, and use a step in the 'other' image recipe to
overwrite it.
But is there a way to tell the image recipe where the app's workdir/srcdir
is? Something like ${WORKDIR}_MyRecipe
Or am I just going to have to hard-code the path in?


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

[yocto] PROVIDES problem building u-boot variants

[colin.helliwell]

Let's see if I can explain this well...

I created a recipe to build a u-boot variant (for prod'n programming) -
"u-boot-PLATFORM-mfg-sec.bb" - which has :

require u-boot-PLATFORM.inc
UBOOT_MACHINE = "tx6s-8035_mfg_sec_config"
SRC_URI += "file://tx6s-8035_mfg_sec_defconfig"

And 'bitbake u-boot-PLATFORM-mfg-sec' works ok with this. 

Now I want to split this out into two different variants, for different
cpu's.

So I begin by renaming the recipe to "u-boot-PLATFORM_tx6s-mfg-sec.bb",
But 'bitbake u-boot-PLATFORM_tx6s-mfg-sec'  throws:
   "Nothing PROVIDES 'u-boot- PLATFORM_tx6s-mfg-sec'"

Can't spot why this simple renaming is breaking things...?



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

[yocto] Specifying MACHINE when setting up build environment

[colin.helliwell]

Is there a way to specify what MACHINE is put into local.conf when first
setting up the build directory with oe-init-build-env?
I have my own TEMPLATECONF which I use, but I'd like to be able to set the
MACHINE on the command line rather than having to then modify local.conf


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

[yocto] Using a poky recipe's files in a custom recipe

[colin.helliwell]

The current Poky I'm using (krogoth) has a recipe for dropbear, but I want
to upgrade to use the latest version of dropbear.
For source control reasons, I don't want to modify what's in
meta/recipes-core/dropbear and therefore want to have my own recipe in my
own layer. Yet for cleanliness I'd also prefer not to have to replicate all
its .inc file etc in my own layer.
Is there a clean way to be able to include meta's files within my own
recipe? Is it a case of some sort of FILESEXTRAPATHS entry, and what would
be the best way to cross reference to the poky layer?



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

[yocto] Slightly varying builds

[colin.helliwell]

I need to build two slightly varying versions of our Yocto build - one for
the production units and one for development.

They differ in only a few ways - the kernel and apps are the same. But one
has Dropbear, whilst the other doesn't; and the U-Boot configs & patches are
different.

 

I'm wondering where to do the separation - image, distro, conf.?

Any thoughts on the cleanest way to split and/or inherit them would be
appreciated.

 

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

[yocto] Custom recipe - resolving "do_package_qa: QA Issue: -dev package contains non-symlink .so"

[colin.helliwell]

I have a custom recipe (for the AWS SDK), which is failing at the package_qa
stage.
The recipe is a very basic cmake styley, and on its own seems to begin with:
'bitbake -f -c package aws-sdk'  completes without errors.

But for 'bitbake -c package_qa aws-sdk) I get: 

ERROR: aws-sdk-1.1.31-r0 do_package_qa: QA Issue: -dev package contains
non-symlink .so: aws-sdk-dev path
'/work/armv7a-neon-poky-linux-gnueabi/aws-sdk/1.1.31-r0/packages-split/aws-s
dk-dev/usr/lib/libaws-cpp-sdk-core.so'
-dev package contains non-symlink .so: aws-sdk-dev path
'/work/armv7a-neon-poky-linux-gnueabi/aws-sdk/1.1.31-r0/packages-split/aws-s
dk-dev/usr/lib/libaws-cpp-sdk-s3.so' [dev-elf]

I'd appreciate help with resolving this. Thanks.


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

[yocto] Understanding dtb generation wrt uboot (with signing)

[colin.helliwell]

I'm working on 2.2/Morty, with a custom board.
Ultimate goal is to create a FIT image with a signed configuration. But I'm
trying to just work through step by step and understand the relationships
between u-boot, kernel, dtb, and the fit image - would appreciate any
guidance!
So far, I've built and booted a fitImage. 

It seems, however, that I need to program my modified dtb into the Flash
(i.MX6 cpu) - if I program in the manufacturer's default then the kernel
doesn't get my modified one. May be a problem for another time - I can
program mine into Flash if need be.

First thing I'm puzzled by is that the dtb *is* in
tmp/deploy/images/mymachine/ , but is called
"zImage--4.4-r0-mymachine-20170727160613.dtb". Also with a symlink
"zImage-mymachine.dtb".  (If I'm understanding things right, this is because
the fitImage contains a compressed kernel...?)

Then I set UBOOT_SIGN_ENABLE = "1", and re-bitbake the u-boot target. It
only gets as far as re-building the kernel, which fails on the
do_assemble_fitimage  stage because uboot-mkimage  is being told to use
"u-boot.dtb"

So I'm unsure what setting(s) I need to tweak to pull things into line. Why
'zImage... .dtb' being built yet 'u-boot.dtb' being looked for?



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

[yocto] Problems with 'configure' on own recipe [after moving to morty]

[colin.helliwell]

This is gonna be a bit of a hard one to describe concisely, but hoping
someone can advise me on solving it
I have a recipe of my own for an app (NetworkManager) which fetches the
source from its git repo. This recipe works on krogoth, but is throwing up
configure errors on morty.

The recipe has a 
do_configure_prepend() {
( cd ${S} ; NOCONFIGURE=yes ./autogen.sh )
}
  - I seemed to need this because the git source has no ABOUT-NLS; not sure
if that's the correct fix, but 'it seemed to work' before. 

The final error is
| DEBUG: Executing shell function do_configure
| ln: failed to create symbolic link '/usr/share/doc/gtk-doc.make':
Permission denied
| cp: cannot create regular file '/usr/share/doc/gtk-doc.make': Permission
denied

I'm not sure why it's trying to make the symlink in the build machine's root
(as I say, it doesn't do this on krogoth)

I'm also getting a lot of:
| NOTE: Skipping setscene dependency
virtual:native:/home/colin/100051-trunk/fsl-community-bsp/sources/poky/meta/
recipes-devtools/pseudo/pseudo_1.8.1.bb:do_populate_sysroot for m4 macro
copying

  - not sure if this is relevant/important

Freely admit I'm no autotools expert, so any suggestions welcome! Thanks



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

[yocto] Migrating from krogoth to morty (can't boot fitImage)

[colin.helliwell]

I'm trying to migrate my krogoth environment to morty. I have custom recipes
for u-boot and kernel; the only change necessary to build under morty was to
patch u-boot for gcc6  - other than that the source versions and configs
used are the same.
On krogoth I can boot a fitImage kernel, but not on morty. (uImage works on
both). 
Looking at the image info on the morty image, it looks like the load/entry
addresses are completely wrong.

On krogoth:
U-Boot > iminfo

## Checking Image at 1800 ...
   FIT image found
   FIT description: U-Boot fitImage for 
Image 0 (kernel@1)
 Description:  Linux kernel
 Type: Kernel Image
 Compression:  uncompressed
 Data Start:   0x18e8
 Data Size:3304552 Bytes = 3.2 MiB
 Architecture: ARM
 OS:   Linux
 Load Address: 0x10008000
 Entry Point:  0x10008000
 Hash algo:sha1
 Hash value:   10a220564569205b11febba4b7e2809395bfee9c
Image 1 (fdt@1)
 Description:  Flattened Device Tree blob
 Type: Flat Device Tree
 Compression:  uncompressed
 Data Start:   0x18326e44
 Data Size:38269 Bytes = 37.4 KiB
 Architecture: ARM
 Hash algo:sha1
 Hash value:   79d5eeb892ef059566c04d98cdc6b30e92a665a2
Default Configuration: 'conf@1'
Configuration 0 (conf@1)
 Description:  Boot Linux kernel with FDT blob
 Kernel:   kernel@1
 FDT:  fdt@1
## Checking hash(es) for FIT Image at 1800 ...
   Hash(es) for Image 0 (kernel@1): sha1+
   Hash(es) for Image 1 (fdt@1): sha1+

On morty:
U-Boot > iminfo

## Checking Image at 1800 ...
   FIT image found
   FIT description: U-Boot fitImage for 
Image 0 (kernel@1)
 Description:  Linux kernel
 Type: Kernel Image
 Compression:  uncompressed
 Data Start:   0x18e8
 Data Size:3304016 Bytes = 3.2 MiB
 Architecture: ARM
 OS:   Linux
 Load Address: 0x01314c40   <- doesn't seem like these could be
correct?
 Entry Point:  0x01314c40
 Hash algo:sha1
 Hash value:   e2de67793e93d854614a42994180b77e053c7302
Image 1 (fdt@1)
 Description:  Flattened Device Tree blob
 Type: Flat Device Tree
 Compression:  uncompressed
 Data Start:   0x18326c2c
 Data Size:38269 Bytes = 37.4 KiB
 Architecture: ARM
 Hash algo:sha1
 Hash value:   79d5eeb892ef059566c04d98cdc6b30e92a665a2
Default Configuration: 'conf@1'
Configuration 0 (conf@1)
 Description:  Linux kernel, FDT blob
 Kernel:   kernel@1
 FDT:  fdt@1
## Checking hash(es) for FIT Image at 1800 ...
   Hash(es) for Image 0 (kernel@1): sha1+
   Hash(es) for Image 1 (fdt@1): sha1+

Attempting to boot causes it to hang after "Loading Kernel Image ... "

Anyone got any ideas what might be wrong, or where to look to track it down?
(Any change to mkimage-type steps in morty?)


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

[yocto] Getting linker -l into a bbappend

[colin.helliwell]

I have an autotools (C++) app which builds fine with my default recipe. But
for a particular platform an additional (C) library is needed, so I have a
bbappend.
I can add in the additional compiler flag here, but I'm struggling to
specify the additional library linkage - I think it's because the ordering
on the linker command line is wrong.

If I add '-lfoo' to the base Makefile.am then it builds fine (though
strangely, "-lfoo" isn't anywhere in the linker command line?). 
But I'm trying to put this into just the 'append' rather than altering the
base [non-platform-specific] Makefile.

I've tried 
EXTRA_OEMAKE += " LDFLAGS+="-lfoo" " 
and
LDFLAGS+="-lrfctrl"
but these don't seem to construct the correct linkage order (functions from
the library are undefined references)

Is there a way to append this in the right way?
Thanks


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

[yocto] Configure errors in my recipe

[colin.helliwell]

I'm trying to put together a recipe for a package (NetworkManager-pptp), but
hitting some peculiar errors in the configure.
I'm building from tarball, and the recipe currently includes
inherit autotools-brokensep gettext
  and
DEPENDS = "intltool-native gettext-native"

I'm not sure what it means by "your autoconf macro directory", but I *can*
see the 'missing' files being put into
networkmanager-pptp/1.2-r0/NetworkManager-pptp-1.2.4/aclocal-copy/

Wondered if anyone can spot what I might be missing?  (Perhaps from
EXTRA_OECONF?)

The log is:

Log data follows:
| DEBUG: Executing python function sysroot_cleansstate
| DEBUG: Python function sysroot_cleansstate finished
| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32',
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
| DEBUG: Executing shell function autotools_preconfigure
| DEBUG: Shell function autotools_preconfigure finished
| DEBUG: Executing python function autotools_copy_aclocals
| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32',
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
| DEBUG: Python function autotools_copy_aclocals finished
| DEBUG: Executing shell function do_configure
| automake (GNU automake) 1.15
| Copyright (C) 2014 Free Software Foundation, Inc.
| License GPLv2+: GNU GPL version 2 or later

| This is free software: you are free to change and redistribute it.
| There is NO WARRANTY, to the extent permitted by law.
|
| Written by Tom Tromey 
|and Alexandre Duret-Lutz .
| AUTOV is 1
| NOTE: Executing glib-gettextize --force --copy
| Copying file po/Makefile.in.in
|
| Please add the files
|   codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4
|   progtest.m4
| from the
/home/colin/100051-trunk/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/u
sr/share/aclocal directory to your autoconf macro directory
| or directly to your aclocal.m4 file.
| You will also need config.guess and config.sub, which you can get from
| ftp://ftp.gnu.org/pub/gnu/config/.
|
| NOTE: Executing intltoolize --copy --force --automake
| NOTE: Executing ACLOCAL="aclocal
--system-acdir=/home/colin/100051-trunk/fsl-community-bsp/build/tmp/work/cor
texa9hf-neon-poky-linux-gnueabi/networkmanager-pptp/1.2-r0/NetworkManager-pp
tp-1.2.4/aclocal-copy/" autoreconf --verbose --install --force
--exclude=autopoint -I
/home/colin/100051-trunk/fsl-community-bsp/build/tmp/work/cortexa9hf-neon-po
ky-linux-gnueabi/networkmanager-pptp/1.2-r0/NetworkManager-pptp-1.2.4/m4/
| autoreconf: Entering directory `.'
| autoreconf: configure.ac: not using Gettext
| autoreconf: running: aclocal
--system-acdir=/home/colin/100051-trunk/fsl-community-bsp/build/tmp/work/cor
texa9hf-neon-poky-linux-gnueabi/networkmanager-pptp/1.2-r0/NetworkManager-pp
tp-1.2.4/aclocal-copy/ -I
/home/colin/100051-trunk/fsl-community-bsp/build/tmp/work/cortexa9hf-neon-po
ky-linux-gnueabi/networkmanager-pptp/1.2-r0/NetworkManager-pptp-1.2.4/m4/ -I
/home/colin/100051-trunk/fsl-community-bsp/build/tmp/work/cortexa9hf-neon-po
ky-linux-gnueabi/networkmanager-pptp/1.2-r0/NetworkManager-pptp-1.2.4/m4/
--force -I m4
| configure.ac:88: warning: macro 'AM_GLIB_GNU_GETTEXT' not found in library
| autoreconf: configure.ac: tracing
| autoreconf: running: libtoolize --copy --force
| libtoolize: putting auxiliary files in '.'.
| libtoolize: copying file './ltmain.sh'
| libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
| libtoolize: copying file 'm4/libtool.m4'
| libtoolize: copying file 'm4/ltoptions.m4'
| libtoolize: copying file 'm4/ltsugar.m4'
| libtoolize: copying file 'm4/ltversion.m4'
| libtoolize: copying file 'm4/lt~obsolete.m4'
| configure.ac:88: warning: macro 'AM_GLIB_GNU_GETTEXT' not found in library
| autoreconf: running:
/home/colin/100051-trunk/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/u
sr/bin/autoconf
--include=/home/colin/100051-trunk/fsl-community-bsp/build/tmp/work/cortexa9
hf-neon-poky-linux-gnueabi/networkmanager-pptp/1.2-r0/NetworkManager-pptp-1.
2.4/m4/ --force
| configure.ac:88: error: possibly undefined macro: AM_GLIB_GNU_GETTEXT
|   If this token and others are legitimate, please use
m4_pattern_allow.
|   See the Autoconf documentation.
| autoreconf:
/home/colin/100051-trunk/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/u
sr/bin/autoconf failed with exit status: 1
| ERROR: autoreconf execution failed.
| ERROR: Function failed: do_configure (log file is located at
/home/colin/100051-trunk/fsl-community-bsp/build/tmp/work/cortexa9hf-neon-po
ky-linux-gnueabi/networkmanager-pptp/1.2-r0/temp/log.do_configure.3514)
ERROR: Task 5
(/home/colin/100051-trunk/fsl-community-bsp/../meta-ln/recipes-connectivity/
networkmanager-pptp/networkmanager-pptp_1.2.bb, do_configure) failed with
exit code '1'
NOTE: Tasks Summary: Attempted 436 tasks of which 434 didn't need to be
rerun and 1 failed.
No currently 

[yocto] Remove/prevent a package's installed files if another package present

[colin.helliwell]

I'd like to do a mod to my ppp recipe such that ip-up & ip-down aren't
installed if another package is in the image recipe i.e. set in
CORE_IMAGE_EXTRA_INSTALL.

I guess I could do a do_install_append() or a pkg_postinst_(), but is there
a way to detect the other package within the recipe? E.g. along the lines of
what PACKAGE_CONF can do for configuration.

Oh, and it needs to work after an update (e.g. rpm/deb) - don't want the
files (re)installed by the update. (So I don't believe
ROOTFS_POSTPROCESS_COMMAND is an option)




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

[yocto] xsltproc failing to load docbook.xsl

[colin.helliwell]

I'm trying to build a package which uses xsltproc, and it's failing to load
docbook.xsl:

|
/home/colin/100051/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/bin
/xsltproc --output man/nmcli.1 --path man --xinclude --nonet --stringparam
man.output.quietly 1 --stringparam funcsynopsis.style ansi --stringparam
man.th.extra1.suppress 1 --stringparam man.authors.section.enabled 0
--stringparam man.copyright.section.enabled 0
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
../NetworkManager-1.6.2/man/nmcli.xml
| I/O error : Attempt to load network entity
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
| warning: failed to load external entity
"http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl;
| cannot parse
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl

I guess I could patch out the '--nonet' for this package, but wondered if
there's a correct way to fix this - a recipe dependency needed and/or
something installed on the host system? 
(I've done a 'sudo apt-get install docbook-xsl docbook-xml'; but can't
figure out where it's expecting the file to be)




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

[yocto] Missing dependencies on driver header

[colin.helliwell]

I have a niggly problem I keep running into, especially with fresh image
builds.
I have a custom driver, and a user-space library for controlling it;
therefore the library includes one of the driver's header files (IOCTL defs
etc). 
However I can't get the dependencies correct in the library recipe so as to
get the driver's header installed and available to the library build step.
In other words 'bitbake MyDriverLib' gives a "MyDriver.h: no such file or
directory "
The lib's recipe includes
inherit autotools lib_package binconfig-disabled pkgconfig
DEPENDS_${PN} = "MyDriver"
RDEPENDS_${PN} = "MyDriver"

At 'some point later', the lib *will* build ok:  I've done each MyDriver
step one by one, and it seems that once the 'install' has been done then
MyDriverLib will then compile. ('-c compile MyDriver' isn't sufficient). But
shouldn't the RDEPENDS above trigger the MyDriver install?
I'm obviously missing a dependency hook somewhere?



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

[yocto] gobject introspection needing pygobject (cross-compilation)

[colin.helliwell]

I've got a few packages in my image which need gobject introspection.
(x86-64 host, ARM target)
One is building fine, but the other - NetworkManager - is failing to
generate the introspection data because it can't analyse the cross-compiled
library. Apparently it uses pygobject in doing this, and thus needs a
version of that for the target architecture.
Are there steps I can take to achieve this? I guess it needs some 'qemu'
technique as with other the G-I support mechanisms?

(Currently working with Krogoth release)



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

[yocto] Unpack hierarchy - jethro vs. krogoth

[colin.helliwell]

Is there a change to recipe parsing and/or variables between jethro and
krogoth?
I'm migrating from the former to the latter and have hit a patch failure.
Looking at the unpacked source, jethro has the relevant file at
build/tmp/work/XXX-poky-linux-gnueabi/linmux/3.0.2-r0/driver/
whereas krogoth has it at
build/tmp/work/XXX-poky-linux-gnueabi/linmux/3.0.2-r0/driver/driver/

Indeed, all the sources have been unpacked under an additional 'driver'
directory level .e.g.
src/driver/*  ->  3.0.2-r0/driver/driver/
src/config/*  ->  3.0.2-r0/driver/config/
instead of 
src/driver/*  ->  3.0.2-r0/driver/
src/config/*  ->  3.0.2-r0/config/


The recipe includes
SRC_URI = "file://driver/*.c \
   file://driver/*.h \
   file://Makefile \
   file://COPYING \
  "
FILESEXTRAPATHS_prepend := "${BSPDIR}/../Apps/MyDriver/src:"
S = "${WORKDIR}"

As I say, it works on jethro...!




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

[yocto] Current situation with gobject introspection?

[colin.helliwell]

I'm currently using Jethro (though about to move to Krogoth), and have an
external package which need gobject introspection. I'm building on 64-bit
x86, for ARM iMX6 target.

I've been searching around to work out if this is possible under Yocto, but
not sure which of the info I've found is up-to-date. 

So I wondered what the latest [krogoth] situation is - am I likely to be
able to get this package to build, and where/how might I get started?

Thanks

 

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

[yocto] Out-of-tree module errors installing its udev rule

[colin.helliwell]

I've got a strange (to me) problem with the recipe for an out-of-tree kernel
module. I'm trying to add a udev rule for the driver - in itself the recipe
does the build ok, but building the full rootfs image throws up a "QA Issue:
linmux: Files/directories were installed but not shipped in any package"
error.

I have

 

inherit module

.

 

SRC_URI += " file://65-linmuxcfg-devnode.rules "

 

S = "${WORKDIR}"

 

FILES_{PN} += "${base_libdir}/udev/rules.d/65-linmuxcfg-devnode.rules"

 

do_install_append(){

install -d ${D}${base_libdir}/udev/rules.d/

install -m 0644 ${WORKDIR}/65-linmuxcfg-devnode.rules
${D}${base_libdir}/udev/rules.d

}

 

Is this because it's an out-of-tree module, or some other [obvious] mistake?

Thanks

 

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

Re: [yocto] DEPENDS only half working

[colin.helliwell]

Fantastic - thanks. (Thought it must have been something simple!)

-Original Message-
From: Patrick Ohly [mailto:patrick.o...@intel.com] 
Sent: 01 February 2017 10:48
To: colin.helliw...@ln-systems.com
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] DEPENDS only half working

On Wed, 2017-02-01 at 10:38 +, colin.helliw...@ln-systems.com wrote:
> I’ve got an odd problem with a pair of recipes:
> 
> App ‘bar’ uses ‘libfoo’, so I’ve set a DEPENDS in bar.bb – I can see 
> this is being half picked up, because ‘bitbake bar’ shows both builds 
> being started. However bar isn’t waiting on libfoo – bar tries to 
> compile before libfoo has even finished configuring, let alone 
> compiled and installed it’s header (foo_lib.h) into sysroot.
> 
> I think the recipes are probably otherwise correct - if I ‘bitbake 
> libfoo’ then ‘bitbake bar’ then all works.
> 
> I’ve looked at some simple lib recipes within poky (e.g.
> libwebp_0.4.3.bb / webkitgtk_2.8.5.bb), and can’t spot anything 
> wrong/missing. Not sure if libfoo should have any ‘install’ or similar 
> sections, or any FILES_ settings, but I was [naively…?] hoping that 
> the inherited classes will be sorting out all that generic kinda 
> stuff.

[...]

> DEPENDS_${PN} = "libfoo"
  ^
This needs to be just "DEPENDS". DEPENDS sets the dependencies for the 
compilation of the entire recipe, whereas...

> RDEPENDS_${PN} = "libfoo"

... RDEPENDS is for runtime dependencies specific packages and thus has 
_ as suffix ($PN = bar in this case).

libfoo gets compiled because of this entry, but because it is a runtime 
dependency, compilation of bar doesn't wait for libfoo's completion.

--
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although I am an 
employee of Intel, the statements I make here in no way represent Intel's 
position on the issue, nor am I authorized to speak on behalf of Intel on this 
matter.




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

[yocto] DEPENDS only half working

[colin.helliwell]

I've got an odd problem with a pair of recipes:

App 'bar' uses 'libfoo', so I've set a DEPENDS in bar.bb - I can see this is
being half picked up, because 'bitbake bar' shows both builds being started.
However bar isn't waiting on libfoo - bar tries to compile before libfoo has
even finished configuring, let alone compiled and installed it's header
(foo_lib.h) into sysroot.

I think the recipes are probably otherwise correct - if I 'bitbake libfoo'
then 'bitbake bar' then all works.

I've looked at some simple lib recipes within poky (e.g. libwebp_0.4.3.bb /
webkitgtk_2.8.5.bb), and can't spot anything wrong/missing. Not sure if
libfoo should have any 'install' or similar sections, or any FILES_
settings, but I was [naively.?] hoping that the inherited classes will be
sorting out all that generic kinda stuff.

 

Anyone help please? 

 

libfoo.bb :

 

.

inherit autotools lib_package binconfig-disabled pkgconfig

RPROVIDES_${PN} = "libfoo"

PROVIDES_${PN} = "libfoo"

PR = "r0"

SRC_URI = " .   "

S = "${WORKDIR}"

 

 

bar.bb :

 

..

inherit autotools binconfig-disabled pkgconfig

DEPENDS_${PN} = "libfoo"

RDEPENDS_${PN} = "libfoo"

S = "${WORKDIR}"

SRC_URI = " .   "

EXTRA_OEMAKE = " CFLAGS=" -I${STAGING_DIR_TARGET}/usr/include/libfoo " "

EXTRA_OEMAKE += " LDFLAGS=" -lfoo " "

 

 

libfoo Makefile.am:

 

lib_LTLIBRARIES = libfoo.la

pkginclude_HEADERS = foo_lib.h  

libfoo_la_SOURCES = $(libfoo_a_HEADERS) foo_lib.c

 

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

Re: [yocto] Making header of out-of-tree module available

[colin.helliwell]

Thanks Daniel,

I’ve given that a try, but the header isn’t appearing (with ‘bitbake rfctrl’) 
anywhere but the module’s own workdir.

It’s recipe is

 

SUMMARY = " RF driver"

LICENSE = "GPLv2"

LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e"

 

inherit module

 

SRC_URI = "file://Makefile \

   file://rfctrl.c \

   file://rfctrl.h \

   file://COPYING \

  "

 

FILES_${PN}-dev = "/usr/include/rfctrl/linux/rfctrl.h"

 

S = "${WORKDIR}"

 

 

With a makefile:

 

obj-m := rfctrl.o

 

SRC := $(shell pwd)

 

all:

$(MAKE) -C $(KERNEL_SRC) M=$(SRC)

 

modules_install:

$(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install

 

clean:

rm -f *.o *~ core .depend .*.cmd *.ko *.mod.c

rm -f Module.markers Module.symvers modules.order

rm -rf .tmp_versions Modules.symvers

 

 

 

From: Daniel. [mailto:danielhi...@gmail.com] 
Sent: 30 January 2017 16:46
To: colin.helliw...@ln-systems.com
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Making header of out-of-tree module available

 

You don't, you make your library depends on your driver, and not on kernel 
exported headers. In my case I add the header to the -dev package and make the 
library compilation depend on kernel module.

# kernel-module-foo.bb  

FILES_${PN}-dev = "/usr/include/foo/linux/foo.h" 

# libfoo.bb  

DEPENDS = "kernel-module-foo"

Cheers

 

2017-01-30 13:37 GMT-02:00  >:

I have a recipe which builds my own (out-of-tree) driver module – this 
packages/installs the module fine. (It’s recipe has “inherit module”). 

Now I’m writing a recipe to build a library which uses the driver. What’s 
needed to get the driver’s header file ‘exported’ so that it can be included by 
the library’s recipe?

Thanks

 


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




-- 

"Do or do not. There is no try"
  Yoda Master

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

[yocto] Making header of out-of-tree module available

[colin.helliwell]

I have a recipe which builds my own (out-of-tree) driver module - this
packages/installs the module fine. (It's recipe has "inherit module"). 

Now I'm writing a recipe to build a library which uses the driver. What's
needed to get the driver's header file 'exported' so that it can be included
by the library's recipe?

Thanks

 

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

Re: [yocto] QEMU with host USB serial

[colin.helliwell]

Hi,
That gives:

Continuing with the following parameters:
KERNEL:
[/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/deploy/images/qemux86-
64/bzImage-qemux86-64.bin]
ROOTFS:
[/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/deploy/images/qemux86-
64/core-image-qemu-qemux86-64-20170124145819.rootfs.ext4]
FSTYPE: [ext4]
Setting up tap interface under sudo
[sudo] password for colin:
Acquiring lockfile for tap0...
Interrupt character is '^]'
-net nic,model=virtio -net tap,vlan=0,ifname=tap0,script=no,downscript=no
-cpu core2duo -drive
file=/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/deploy/images/qemu
x86-64/core-image-qemu-qemux86-64-20170124145819.rootfs.ext4,if=virtio,forma
t=raw -show-cursor -usb -usbdevice wacom-tablet -vga vmware   -nographic
-serial stdio  -m 256
Running qemu-system-x86_64...
/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/sysroots/x86_64-linux/u
sr/bin/qemu-system-x86_64 -kernel
/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/deploy/images/qemux86-6
4/bzImage-qemux86-64.bin -net nic,model=virtio -net
tap,vlan=0,ifname=tap0,script=no,downscript=no -cpu core2duo -drive
file=/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/deploy/images/qemu
x86-64/core-image-qemu-qemux86-64-20170124145819.rootfs.ext4,if=virtio,forma
t=raw -show-cursor -usb -usbdevice wacom-tablet -vga vmware -no-reboot
-nographic -serial stdio -m 256 -serial null --append "vga=0
uvesafb.mode_option=640x480-32 root=/dev/vda rw mem=256M
ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 rootfstype=ext4
console=ttyS0 console=ttyS0"
QEMU 2.4.0 monitor - type 'help' for more information
(qemu) qemu-system-x86_64: -serial stdio: cannot use stdio by multiple
character devices
Set 'tap0' nonpersistent
Releasing lockfile of preconfigured tap device 'tap0'


-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
On Behalf Of Khem Raj
Sent: 27 January 2017 02:10
To: yocto@yoctoproject.org
Subject: Re: [yocto] QEMU with host USB serial

On 1/26/17 6:22 AM, colin.helliw...@ln-systems.com wrote:
> I'm investigating using qemu to give us some test capability, for 
> which we need to use the host's serial devices.
> 
> I have a qemu build which boots up fine; I'm trying to give it access 
> to the host USB. To keep it simple(r), I've seen mention of FTDI's 
> device
> (0403:6001) in the qemu source so that's what I've plugged in. I've 
> done a 'chmod me:me' on the relevant /dev/bus/usb/xxx/yyy node.
> 
>  
> 
> I can't though figure out what options I should be passing to runqemu 
> to hook this in. I daresay I may need bootparams too, but am first 
> just trying to get past 'qemuparams'.
> 
> As a starting point, I'm trying things like
> 
> runqemu qemux86-64 nographic qemuparams="-usbdevice serial"

can you try with

runqemu qemux86-64 nographic serial

--
___
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] QEMU with host USB serial

[colin.helliwell]

'chown' that is, not 'chmod'!

 

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
On Behalf Of colin.helliw...@ln-systems.com
Sent: 26 January 2017 14:22
To: 'Yocto discussion list' 
Subject: [yocto] QEMU with host USB serial

 

.. I've done a 'chmod me:me' on the relevant /dev/bus/usb/xxx/yyy node.

 

 

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

[yocto] QEMU with host USB serial

[colin.helliwell]

I'm investigating using qemu to give us some test capability, for which we
need to use the host's serial devices.

I have a qemu build which boots up fine; I'm trying to give it access to the
host USB. To keep it simple(r), I've seen mention of FTDI's device
(0403:6001) in the qemu source so that's what I've plugged in. I've done a
'chmod me:me' on the relevant /dev/bus/usb/xxx/yyy node.

 

I can't though figure out what options I should be passing to runqemu to
hook this in. I daresay I may need bootparams too, but am first just trying
to get past 'qemuparams'.

As a starting point, I'm trying things like

runqemu qemux86-64 nographic qemuparams="-usbdevice serial"

 

which reports

 

Continuing with the following parameters:

KERNEL:
[/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/deploy/images/qemux86-
64/bzImage-qemux86-64.bin]

ROOTFS:
[/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/deploy/images/qemux86-
64/core-image-qemu-qemux86-64-20170124145819.rootfs.ext4]

FSTYPE: [ext4]

Setting up tap interface under sudo

Acquiring lockfile for tap0...

-net nic,model=virtio -net tap,vlan=0,ifname=tap0,script=no,downscript=no
-cpu core2duo -drive
file=/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/deploy/images/qemu
x86-64/core-image-qemu-qemux86-64-20170124145819.rootfs.ext4,if=virtio,forma
t=raw -show-cursor -usb -usbdevice wacom-tablet -vga vmware   -nographic
-usbdevice serial -m 256

Running qemu-system-x86_64...

/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/sysroots/x86_64-linux/u
sr/bin/qemu-system-x86_64 -kernel
/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/deploy/images/qemux86-6
4/bzImage-qemux86-64.bin -net nic,model=virtio -net
tap,vlan=0,ifname=tap0,script=no,downscript=no -cpu core2duo -drive
file=/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/deploy/images/qemu
x86-64/core-image-qemu-qemux86-64-20170124145819.rootfs.ext4,if=virtio,forma
t=raw -show-cursor -usb -usbdevice wacom-tablet -vga vmware -no-reboot
-nographic -usbdevice serial -m 256 -serial mon:stdio -serial null --append
"vga=0 uvesafb.mode_option=640x480-32 root=/dev/vda rw mem=256M
ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 rootfstype=ext4
console=ttyS0"

qemu-system-x86_64: -usbdevice serial: character device specification needed

qemu-system-x86_64: -usbdevice serial: Failed to create USB device
'usb-serial'

qemu: could not add USB device 'serial'

Set 'tap0' nonpersistent

Releasing lockfile of preconfigured tap device 'tap0'

 

Or

   runqemu qemux86-64 nographic qemuparams="-device
usb-serial,vendorid=0403,productid=6001"

 

which reports

 

Please use simplified serial or kvm options instead

Continuing with the following parameters:

KERNEL:
[/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/deploy/images/qemux86-
64/bzImage-qemux86-64.bin]

ROOTFS:
[/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/deploy/images/qemux86-
64/core-image-qemu-qemux86-64-20170124145819.rootfs.ext4]

FSTYPE: [ext4]

Setting up tap interface under sudo

Acquiring lockfile for tap0...

-net nic,model=virtio -net tap,vlan=0,ifname=tap0,script=no,downscript=no
-cpu core2duo -drive
file=/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/deploy/images/qemu
x86-64/core-image-qemu-qemux86-64-20170124145819.rootfs.ext4,if=virtio,forma
t=raw -show-cursor -usb -usbdevice wacom-tablet -vga vmware   -nographic
-device usb-serial,vendorid=0403,productid=6001 -m 256

Running qemu-system-x86_64...

/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/sysroots/x86_64-linux/u
sr/bin/qemu-system-x86_64 -kernel
/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/deploy/images/qemux86-6
4/bzImage-qemux86-64.bin -net nic,model=virtio -net
tap,vlan=0,ifname=tap0,script=no,downscript=no -cpu core2duo -drive
file=/home/colin/100051-karo/fsl-community-bsp/buildq/tmp/deploy/images/qemu
x86-64/core-image-qemu-qemux86-64-20170124145819.rootfs.ext4,if=virtio,forma
t=raw -show-cursor -usb -usbdevice wacom-tablet -vga vmware -no-reboot
-nographic -device usb-serial,vendorid=0403,productid=6001 -m 256 -serial
null --append "vga=0 uvesafb.mode_option=640x480-32 root=/dev/vda rw
mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1
rootfstype=ext4 console=ttyS0"

QEMU 2.4.0 monitor - type 'help' for more information

(qemu) usb_device_add 1 'wacom-tablet'

usb_device_add success 'wacom-tablet'

qemu-system-x86_64: -device usb-serial,vendorid=0403,productid=6001:
Property '.vendorid' not found

Set 'tap0' nonpersistent

Releasing lockfile of preconfigured tap device 'tap0'

 

 

Can someone clue me in on the correct syntax please!

Thanks

 

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

Re: [yocto] Changing over to systemd (no dhcp)

[colin.helliwell]

Looking at it in more detail, it's perhaps more that not everything is taken up 
by systemd i.e. I have lots of symlinks to /dev/null in etc/systemd/system, 
with the corresponding/original SysV script still in /etc/init.d.  Things like 
banner, sysfs, urandom, dmesg (to name just a few).
Maybe these don't matter but, as I say, it just seems like a bit of 'clutter'

Looking at one which does seem to switch over cleanly - dropbear - I'm puzzled 
how the recipe [dropbear.inc, in poky/meta/recipes-core] appears to install 
both init.d script and .service in its do_install, yet only one or the other 
ultimately shows up in the rootfs..? (Relates to my other question about how to 
determine the init type in do_install)

-Original Message-
From: Leon Woestenberg [mailto:l...@sidebranch.com] 
Sent: 21 January 2017 13:09
To: colin.helliw...@ln-systems.com
Cc: Yocto discussion list 
Subject: Re: [yocto] Changing over to systemd (no dhcp)

Hi Colin,

On Fri, Jan 20, 2017 at 2:59 PM,  wrote:
>
> DISTRO_FEATURES_remove = " sysvinit"
>
> I suspect there’s also some de-cluttering needed e.g. init.d scripts still 
> being installed as well as a .service.
>
I wouldn't expect these to be installed.  Which ones specifically?

Regards,

Leon.

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

Re: [yocto] Changing over to systemd (no dhcp)

[colin.helliwell]

Thanks for all the pointers everyone. I've now got (in my distro conf):

DISTRO_FEATURES_append = " systemd"

DISTRO_FEATURES_remove = " sysvinit"

VIRTUAL-RUNTIME_init_manager = "systemd"

PREFERRED_PROVIDER_udev = "systemd"

PACKAGECONFIG_append_pn-systemd = " resolved networkd"

 

It's booting fine (if 'noisily'!) and starting up dhcp. 

I suspect there's also some de-cluttering needed e.g. init.d scripts still
being installed as well as a .service.  On that subject, is there some
clever syntax for a do_install() and/or recipe in order to control which
type of file is installed into rootfs?

 

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

Re: [yocto] Changing over to systemd (no dhcp)

[colin.helliwell]

Thanks Chen.

Currently looking into getting networkd hooked in. (no luck yet!)

I'll also look into moving stuff from local.conf to elsewhere, but where you
say "Distro conf files are not suitable for such kinds of modification", I'm
wondering what sort of modifications they *are* suitable/intended for? (i.e.
the purpose of a distro as opposed to an image recipe)

 

From: ChenQi [mailto:qi.c...@windriver.com] 
Sent: 19 January 2017 08:32
To: colin.helliw...@ln-systems.com; 'Rick Altherr' ;
'Andre McCurdy' 
Cc: 'Yocto discussion list' 
Subject: Re: [yocto] Changing over to systemd (no dhcp)

 

Hi Colin,

For the dhcp problem, what you need is a network manager. Any network
manager that supports dhcp would do the job. systemd-networkd might be
sufficient in your case.

For the local.conf problem, you could use a layer to manage all common
things shared by the team.

For the package adding problem, it depends on the purpose.
1) if adding the package is only for local work (dev or test), do it in
local.conf
2) otherwise, do it in image recipe
Distro conf files are not suitable for such kinds of modification.

Best Regards,
Chen Qi

On 01/19/2017 03:21 PM, colin.helliw...@ln-systems.com
  wrote:

Yes, I'd agree with that, Rick.

We run automated regression builds from a fresh version control checkout -
but because local.conf is generated when the build environment is set up, it
isn't suitable for version control. So any mods to it found during
development have to be (remembered to be) put into local.conf.sample, so
that the same build is assured for anyone anywhere.

I've long felt/assumed that local.conf was for truly local mods, for that
user and/or for their temporary try-outs.

Similarly - and this is going even more off-topic so I'll save the detail
for a separate thread - I've still not yet got to grips with whether, when I
want to add a particular package, I should be modifying my image recipe or
set up a custom distro)

 

From: Rick Altherr [mailto:ralth...@google.com] 
Sent: 19 January 2017 00:22
To: Andre McCurdy   
Cc: colin.helliw...@ln-systems.com  ;
Yocto discussion list  

Subject: Re: [yocto] Changing over to systemd (no dhcp)

 

I was wondering about this recently.  Why are these snippets put in
local.conf.sample.extended instead of separate, well-named .inc files that
can be shared by multiple distros?  The current model seems to encourage
putting lots of configuration in local.conf that probably should be in the
distro or machine conf.

 

Rick

 

On Wed, Jan 18, 2017 at 1:35 PM, Andre McCurdy  > wrote:

On Wed, Jan 18, 2017 at 7:10 AM,   > wrote:

> We have a configuration for our embedded system which is working via SysV,
> but we're investigating moving over to systemd.
>
> Not sure if this is 'wise' - if anyone has technological arguments
> for/against then I'd be interested - but I wanted to investigate it
anyway.
>
> I've modified local.conf (right or wrong) with
>
>   DISTRO_FEATURES_append = " systemd"
>   VIRTUAL-RUNTIME_init_manager = "systemd"
>   DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
>   VIRTUAL-RUNTIME_initscripts = ""
>   KERNEL_ENABLE_CGROUPS = "1"
>
> I also found a readme
> (https://cgit.freedesktop.org/systemd/systemd/tree/README#n37) about the
> kernel requirements for systemd, and it does at least now boot.
>
> However although eth0 is coming up ('ifconfig eth0'), there doesn't seem
to
> be any dhcp happening - no IP etc.
>
> Previously (under SysV) I had the busybox dhcp client; now it seems that
is
> missing. There's a symlink /etc/systemd/system/busybox-udhcpc.service to
> /dev/null
>
> I'm using
>
>   Poky Jethro
>   Kernel 4.4.0
>   Busybox 1.23.2 (with 'CONFIG_FEATURE_SYSTEMD=y')
>
> I wondered if this is just a simple switch I'm missing somewhere, or is
> there a whole load more modifications I need to dig into and hand-craft?
> (Was hoping for something 'out of the box'..)

Try:

  VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"

Enabling systemd is somewhat documented by the example in
{meta-poky,openembedded-core/meta}/conf/local.conf.sample.extended,
which is:

#
# Use systemd for system initialization
#
# DISTRO_FEATURES_append = " systemd"
# DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
# VIRTUAL-RUNTIME_init_manager = "systemd"
# VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"

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

 





 

-- 
___
yocto mailing list
yocto@yoctoproject.org

Re: [yocto] Changing over to systemd (no dhcp)

[colin.helliwell]

Yes, I’d agree with that, Rick.

We run automated regression builds from a fresh version control checkout – but 
because local.conf is generated when the build environment is set up, it isn’t 
suitable for version control. So any mods to it found during development have 
to be (remembered to be) put into local.conf.sample, so that the same build is 
assured for anyone anywhere.

I’ve long felt/assumed that local.conf was for truly local mods, for that user 
and/or for their temporary try-outs.

Similarly – and this is going even more off-topic so I’ll save the detail for a 
separate thread – I’ve still not yet got to grips with whether, when I want to 
add a particular package, I should be modifying my image recipe or set up a 
custom distro)

 

From: Rick Altherr [mailto:ralth...@google.com] 
Sent: 19 January 2017 00:22
To: Andre McCurdy 
Cc: colin.helliw...@ln-systems.com; Yocto discussion list 

Subject: Re: [yocto] Changing over to systemd (no dhcp)

 

I was wondering about this recently.  Why are these snippets put in 
local.conf.sample.extended instead of separate, well-named .inc files that can 
be shared by multiple distros?  The current model seems to encourage putting 
lots of configuration in local.conf that probably should be in the distro or 
machine conf.

 

Rick

 

On Wed, Jan 18, 2017 at 1:35 PM, Andre McCurdy  > wrote:

On Wed, Jan 18, 2017 at 7:10 AM,   > wrote:

> We have a configuration for our embedded system which is working via SysV,
> but we’re investigating moving over to systemd.
>
> Not sure if this is ‘wise’ – if anyone has technological arguments
> for/against then I’d be interested – but I wanted to investigate it anyway.
>
> I’ve modified local.conf (right or wrong) with
>
>   DISTRO_FEATURES_append = " systemd"
>   VIRTUAL-RUNTIME_init_manager = "systemd"
>   DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
>   VIRTUAL-RUNTIME_initscripts = ""
>   KERNEL_ENABLE_CGROUPS = "1"
>
> I also found a readme
> (https://cgit.freedesktop.org/systemd/systemd/tree/README#n37) about the
> kernel requirements for systemd, and it does at least now boot.
>
> However although eth0 is coming up (‘ifconfig eth0’), there doesn’t seem to
> be any dhcp happening – no IP etc.
>
> Previously (under SysV) I had the busybox dhcp client; now it seems that is
> missing. There’s a symlink /etc/systemd/system/busybox-udhcpc.service to
> /dev/null
>
> I’m using
>
>   Poky Jethro
>   Kernel 4.4.0
>   Busybox 1.23.2 (with ‘CONFIG_FEATURE_SYSTEMD=y’)
>
> I wondered if this is just a simple switch I’m missing somewhere, or is
> there a whole load more modifications I need to dig into and hand-craft?
> (Was hoping for something ‘out of the box’….)

Try:

  VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"

Enabling systemd is somewhat documented by the example in
{meta-poky,openembedded-core/meta}/conf/local.conf.sample.extended,
which is:

#
# Use systemd for system initialization
#
# DISTRO_FEATURES_append = " systemd"
# DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
# VIRTUAL-RUNTIME_init_manager = "systemd"
# VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"

--
___
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] Changing over to systemd (no dhcp)

[colin.helliwell]

We have a configuration for our embedded system which is working via SysV,
but we're investigating moving over to systemd. 

Not sure if this is 'wise' - if anyone has technological arguments
for/against then I'd be interested - but I wanted to investigate it anyway.

 

I've modified local.conf (right or wrong) with

  DISTRO_FEATURES_append = " systemd"

  VIRTUAL-RUNTIME_init_manager = "systemd"

  DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"

  VIRTUAL-RUNTIME_initscripts = ""

  KERNEL_ENABLE_CGROUPS = "1"

 

I also found a readme
(https://cgit.freedesktop.org/systemd/systemd/tree/README#n37) about the
kernel requirements for systemd, and it does at least now boot.

However although eth0 is coming up ('ifconfig eth0'), there doesn't seem to
be any dhcp happening - no IP etc.

Previously (under SysV) I had the busybox dhcp client; now it seems that is
missing. There's a symlink /etc/systemd/system/busybox-udhcpc.service to
/dev/null

I'm using 

  Poky Jethro

  Kernel 4.4.0

  Busybox 1.23.2 (with 'CONFIG_FEATURE_SYSTEMD=y')

 

I wondered if this is just a simple switch I'm missing somewhere, or is
there a whole load more modifications I need to dig into and hand-craft?
(Was hoping for something 'out of the box'..)

 

Thanks

 

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

Re: [yocto] Adding to inittab based on image content

[colin.helliwell]

Thanks Rudi, that's got it.

-Original Message-
From: Rudolf J Streif [mailto:rudolf.str...@gmail.com] 
Sent: 06 January 2017 17:18
To: yocto@yoctoproject.org; colin.helliw...@ln-systems.com
Subject: Re: [yocto] Adding to inittab based on image content

Hi Colin,

The correct way of doing this is a package postinstallation script that is
run by the package manager after the package containing your application is
installed on the target system.

You add to your recipe:

pkg_postinst_${PN}() {
#!/bin/sh
echo "whateveryouneed" >> ${D}/etc/inittab }

The build system will include this as the post install script into the
package in the correct form for the package manager you are using e.g. RPM,
DEB, IPK.

This will work when the build system installs your package into the system
root or when executed on the target.

You can also distinguish the two cases:

pkg_postinst_${PN}() {
#!/bin/sh
if [ x"$D" = "x" ] ; then
   # shell commands for target execution else
   # shell commands for build system execution fi }

In the case of target execution $D is not set.


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

[yocto] Adding to inittab based on image content

[colin.helliwell]

Hi,

I have a custom recipe for an application, and the app also needs an entry
adding to inittab. I'd like to trigger this, obviously, only when the app is
included in the image.

I came across some hints at how to do this -
http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-c
ore/sysvinit/sysvinit-inittab_2.88dsf.bbappend?h=dizzy - but the app isn't
in DISTRO_FEATURES. (Right or wrong.., I include it in the image with a
"CORE_IMAGE_EXTRA_INSTALL +=" in my image recipe).

Any suggestions on how to make this inittab addition conditional?

Thanks

 

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

[yocto] Building a package for target and native

[colin.helliwell]

I'm creating a recipe for a 3rd party package. 

Part of its install is to create the target's config file by running
*itself* - obviously this doesn't work as the target cpu is different to the
host.

I should be able to do a simple patch to alter the executable that the
Makefile runs to generate the config file, but I'm trying to figure out the
slickest (=correct!) way to get both architectures built.

It looks like I can add 

   BBCLASSEXTEND="native"

to the recipe and then 'bitbake mypkg-native' will build for native, and
'bitbake mypkg' for the target.

In which case, can I set up a dependency rule such that the target build is
dependent on, i.e run after, the native? 

(The package itself will be pulled in with a   IMAGE_INSTALL += " mypkg ")

Or is there a better approach to this in general?   e.g. a separate
mypkg-native.bb which the target recipe then depends on.

 

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

[yocto] Adding a file into the kernel source

[colin.helliwell]

I want to add a new file (a device tree source) into my kernel build. Is
there a way to get the recipe to specifically copy an existing file in , or
does it have to be created using a patch?

 

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