[yocto] How to install kernel objects in /lib

[Damien LEFEVRE]

Hi,

I made a recipe to build and install a kernel object. See

SUMMARY = "Kernel module for EPIX grabber"
LICENSE = "CLOSED"

inherit module

SRC_URI = "file://Makefile \
   file://pixcilnx_aarch64_4.4.a \
   file://pixcipub.c \
   file://pixcipub.h \
   file://pixci.rc \
   file://pixci.conf \
  "

S = "${WORKDIR}"

# The inherit of module.bbclass will automatically name module packages with
# "kernel-module-" prefix as required by the oe-core build environment.

do_install() {
# First create the directories
install -d
${D}${base_libdir}/modules/${KERNEL_VERSION}/kernel/drivers/misc
install -d ${D}${sysconfdir}/init.d
install -d ${D}${sysconfdir}/default/

# Then add the files
install -m 555 -g root -o root ${B}/pixci.ko ${D}${base_libdir
}/modules/${KERNEL_VERSION}/kernel/drivers/misc/pixci.ko
install -m 555 -g root -o root ${WORKDIR}/pixci.rc
${D}${sysconfdir}/init.d/pixci
install -m 644 -g root -o root ${WORKDIR}/pixci.conf
${D}${sysconfdir}/default/pixci
}

# Include all installed files from /etc and /lib
FILES_${PN} += "${base_libdir
}/modules/${KERNEL_VERSION}/kernel/drivers/misc/pixci.ko"
FILES_${PN} += "${sysconfdir}/init.d/pixci"
FILES_${PN} += "${sysconfdir}/default/pixci"

If I use base_libdir to install the kernel object where the scripts expect
it to be, I get an error:
nothing provides kernel-module-pixci-4.4.38-l4t-r28.1+g79e4600 needed by
pixci-3.8.01-r0.jetson_tx2

But if I use libdir variable the kernel object is packages and installed
properly.

Could anyone explain me why?

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

[yocto] LINUX_VERSION issue in recipe

[Damien LEFEVRE]

Hi,

This must be a stupid basic question. I have the following recipe append:

keymaps_1.0.bbappend
-
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI_append = " file://keymaps.service \
   file://keymap.sh \
"

do_install_append() {
install -d ${D}${sysconfdir}
ln -sf /usr/share/keymaps/i386/qwerty/fi.map.gz
${D}${sysconfdir}/keymap-${LINUX_VERSION}.map.gz

install -d ${D}${systemd_system_unitdir}
install -m 0644 ${WORKDIR}/keymaps.service ${D}${systemd_system_unitdir}
}

FILES_${PN} += " ${sysconfdir}/* \
 ${systemd_system_unitdir}/* \
"

inherit systemd
SYSTEMD_SERVICE_${PN} = "${PN}.service"
-

The LINUX_VERSION is not expanded and the final symlink name becomes  /etc/
keymap-.map.gz.

What's correct way to get the linux version in the recipe files?

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

Re: [yocto] LINUX_VERSION issue in recipe

[Damien LEFEVRE]

 OK, thanks for the clarification guys!

I think I'll just overwrite the keymaps recipe script to get rid of the
kernel version and continue from here =)

Cheers,
-Damien


On Sat, Apr 28, 2018 at 5:20 AM, Bruce Ashfield <
bruce.ashfi...@windriver.com> wrote:

>
>
> On 4/27/2018 5:34 PM, Andre McCurdy wrote:
>
>> On Fri, Apr 27, 2018 at 3:44 AM, Damien LEFEVRE 
>> wrote:
>>
>>> Hi,
>>>
>>> This must be a stupid basic question. I have the following recipe append:
>>>
>>> keymaps_1.0.bbappend
>>> 
>>> -
>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>> SRC_URI_append = " file://keymaps.service \
>>> file://keymap.sh \
>>> "
>>>
>>> do_install_append() {
>>>  install -d ${D}${sysconfdir}
>>>  ln -sf /usr/share/keymaps/i386/qwerty/fi.map.gz
>>> ${D}${sysconfdir}/keymap-${LINUX_VERSION}.map.gz
>>>
>>>  install -d ${D}${systemd_system_unitdir}
>>>  install -m 0644 ${WORKDIR}/keymaps.service
>>> ${D}${systemd_system_unitdir}
>>> }
>>>
>>> FILES_${PN} += " ${sysconfdir}/* \
>>>   ${systemd_system_unitdir}/* \
>>> "
>>>
>>> inherit systemd
>>> SYSTEMD_SERVICE_${PN} = "${PN}.service"
>>> 
>>> -
>>>
>>> The LINUX_VERSION is not expanded and the final symlink name becomes
>>> /etc/keymap-.map.gz.
>>>
>>> What's correct way to get the linux version in the recipe files?
>>>
>>
>> In general, there isn't a correct way to do that. The LINUX_VERSION
>> variable is defined within the kernel recipe and other recipes won't
>> have access to it.
>>
>> A core concept in OE is that recipes build independently of each
>> other. In this case, since the keymaps recipe has no direct dependency
>> on the kernel, you should not expect the keymaps recipe to be rebuilt
>> (or affected in any way) when the kernel or kernel version changes.
>>
>
> Yep. Unless you inherit the kernel build classes there's no
> easy way to do this. But if the kernel classes are inherited,
> then some of the variables like KERNEL_VERSION become available
> to use .. but of course, you've just tightly coupled things to
> the kernel.
>
> Cheers,
>
> Bruce
>
>
>
>> The keymaps init script ( meta/recipes-bsp/keymaps/files/keymap.sh )
>> detects the kernel version dynamically at runtime. If you need a
>> kernel version specific symlink in your target rootfs, maybe you could
>> create it at runtime from your keymaps service file?
>>
>>


-- 
___

LEFEVRE Damien
lefevre...@gmail.com
http://www.lfdm.net
044 598 4475, Finland (+358)
Nikkarinhaka 6
90450 Kempele, FINLAND
  ___
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Splash screen using systemd

[Damien LEFEVRE]

Hi,

I'm working on an NVidia Jetson board with a TX2 module and I would like to
have splash screen with a progress bar when booting and shutting down. The
board boots to an application embedded style. There's no desktop and no
user login.

The configuration I use makes use of systemd.

I gave a try to psplash but by now I have realized that it is not
compatible with systemd. The image is displayed but I don't get progress
information.

Next try with dietsplash. The splash screen isn't displayed and I just have
a black screen when booting. If I manually run /bin/dietsplash I lose
control over the keyboard and the penguin isn't displayed.

The dietsplash doc https://github.com/lucasdemarchi/dietsplash/tree/v0.3
mentions to add 'init=/bin/dietsplash' to the kernel command line.

What would be the way to I add it?

Last try plymouth. An error comes during the boot and the splash screen
doesn't show:
[   OK] Started Show Plymouth Boot Screen.
[FAILED] Failed to start Forward Passwrod Requests to Plymouth Directory
Watch.
See 'systemctl status systemd-ask-password-plymouth.path' for details

systemctl status gives me:
● systemd-ask-password-plymouth.path - Forward Password Requests to
Plymouth Directory Watch
   Loaded: loaded (/lib/systemd/system/systemd-ask-password-plymouth.path;
static; vendor preset: enabled)
   Active: inactive (dead)
 Docs: http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents

May 02 14:34:10 jetson-tx2 systemd[1]:
[[0;1;31msystemd-ask-password-plymouth.path: Refusing to start, unit to
trigger not loaded.[[0m
May 02 14:34:10 jetson-tx2 systemd[1]: [[0;1;31mFailed to start Forward
Password Requests to Plymouth Directory Watch.[[0m

Any hint would be greatly appreciated :D

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

[yocto] LIC_FILES_CHKSUM: spaces in file names

[Damien LEFEVRE]

Hi,

I have a base recipe generated with devtool.

The package I build has several license files which contain space
characters in the file names.

LIC_FILES_CHKSUM =
"file://COPYRIGHT.md;md5=b229ca0c79785e9e86311477e7bdd9ea \
 file://LICENSES/MIT
License.txt;md5=3ba96e7848c3cedc5df2d00094a0d0f3 \
 file://LICENSES/FreeImage Public
License.txt;md5=ffcd65468a2d2b3e3e43fbaf63ceedf7 \
 file://LICENSES/Boost Software
License.txt;md5=2c7a3fa82e66676005cd4ee2608fd7d2 \
 file://LICENSES/zlib-libpng
License.txt;md5=09b00738058950409d6955872d715416 \
 file://LICENSES/OpenSIFT
License.txt;md5=7a69fc0ac94076df51f7db9b0c02fe7c \
 file://LICENSES/ISSL
License.txt;md5=1ba0d78ed416760e4a8ef3dc121e69c8"

Bitbake fails and seem to break at the first space character
LIC_FILES_CHKSUM contains an invalid URL:
License.txt;md5=3ba96e7848c3cedc5df2d00094a0d0f3

How can I deal with this? Any other options than renaming the files?

I tried surrounding with quotes, "\ "using, nothing helps.

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

Re: [yocto] LIC_FILES_CHKSUM: spaces in file names

[Damien LEFEVRE]

Thanks Mark it works.

-Damien

On Tue, May 15, 2018, 17:29 Mark Hatle  wrote:

> On 5/15/18 7:25 AM, Damien LEFEVRE wrote:
> > Hi,
> >
> > I have a base recipe generated with devtool.
> >
> > The package I build has several license files which contain space
> characters in
> > the file names.
> >
> > LIC_FILES_CHKSUM =
> "file://COPYRIGHT.md;md5=b229ca0c79785e9e86311477e7bdd9ea \
> >  file://LICENSES/MIT
> > License.txt;md5=3ba96e7848c3cedc5df2d00094a0d0f3 \
> >  file://LICENSES/FreeImage Public
> > License.txt;md5=ffcd65468a2d2b3e3e43fbaf63ceedf7 \
> >  file://LICENSES/Boost Software
> > License.txt;md5=2c7a3fa82e66676005cd4ee2608fd7d2 \
> >  file://LICENSES/zlib-libpng
> > License.txt;md5=09b00738058950409d6955872d715416 \
> >  file://LICENSES/OpenSIFT
> > License.txt;md5=7a69fc0ac94076df51f7db9b0c02fe7c \
> >  file://LICENSES/ISSL
> > License.txt;md5=1ba0d78ed416760e4a8ef3dc121e69c8"
> >
> > Bitbake fails and seem to break at the first space character
> > LIC_FILES_CHKSUM contains an invalid URL:
> > License.txt;md5=3ba96e7848c3cedc5df2d00094a0d0f3
> >
> > How can I deal with this? Any other options than renaming the files?
> >
> > I tried surrounding with quotes, "\ "using, nothing helps.
>
> I've not tried it, but since these are URIs, did you try %20?
>
> --Mark
>
> > Thanks,
> > -Damien
> >
> >
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] native recipe question

[Damien LEFEVRE]

Hi,

I'm having to build a package (arrayfire) for Tegra. This package requires
to first build a x86_64 utility (bin2cpp) which is then used for building
the tegra arrayfire.

Do I understand correctly that I should create:

   - arrayfire-native.bb: for compiling the x86_64 utility. If so how do I
   instruct the platform?
   - arrayfire.bb: for compiling the tegra platform. This recipe requires
   arrayfire-native.bb and I should get a copy in the recipe-sysroot-native
   folder?

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

Re: [yocto] native recipe question

[Damien LEFEVRE]

Thanks that did the trick.

I actually needed to add the tool compilation in do_configure_prepend
because the cmake configuration requires the output folder for bin2cpp.

Just out of completeness. I had created that arrayfire-native recipe and it
looked like this:

BBCLASSEXTEND = "native"
SRC_URI = "gitsm://
github.com/arrayfire/arrayfire.git;protocol=https;branch=v3.6"
SRCREV = "ee21c791d5af4fa56bca168804ba1597cf9d6503"

PR="r0"

S = "${WORKDIR}/git"

inherit cmake cuda

do_configure(){
cd ${B}
cmake ${S} \
-DAF_BUILD_CPU=OFF \
-DAF_BUILD_CUDA=OFF \
-DAF_BUILD_OPENCL=OFF \
-DAF_BUILD_EXAMPLES=OFF \
-DAF_BUILD_TEST=OFF \
-DAF_WITH_GRAPHICS=OFF \
-DCMAKE_BUILD_TYPE=Release
}

do_compile(){
make bin2cpp
}

do_install() {
install -d ${D}/${bindir}
install -m 755 ${WORKDIR}/build/bin2cpp ${D}${bindir}
}

# Defining packages
FILES_${PN} = "${bindir}/*"


The recipe builds. When I try using with  DEPENDS += "arrayfire-native" in
the arrayfire recipe I get this warning:
WARNING: arrayfire-3.6.0-r0 do_prepare_recipe_sysroot: Manifest
/home/damien/pyro/build-jetson-tx2/tmp/sstate-control/manifest-x86_64-arrayfire-native.populate_sysroot
not found?

and 
/home/damien/pyro/build-jetson-tx2/tmp/work/aarch64_tegra186-poky-linux/arrayfire/3.6.0-r0/recipe-sysroot-native
did not contain the bin2cpp binary.

What did I miss?

Thanks


On Tue, May 22, 2018 at 12:19 PM, Burton, Ross 
wrote:

> On 22 May 2018 at 08:43, Damien LEFEVRE  wrote:
> > I'm having to build a package (arrayfire) for Tegra. This package
> requires
> > to first build a x86_64 utility (bin2cpp) which is then used for building
> > the tegra arrayfire.
> >
> > Do I understand correctly that I should create:
> >
> > arrayfire-native.bb: for compiling the x86_64 utility. If so how do I
> > instruct the platform?
> > arrayfire.bb: for compiling the tegra platform. This recipe requires
> > arrayfire-native.bb and I should get a copy in the recipe-sysroot-native
> > folder?
>
> That's one solution, but if it's jus a single tool that you need built
> then you can build that yourself using the host compiler.  The best
> practise here is for the upstream build to respect CC_FOR_BUILD ("use
> this compiler to build binaries that I need to run at build time")
> which we already export.  As presumably arrayfire doesn't do this,
> then you can just build it yourself first.  For example, the Pango
> recipe in oe-core basically does this:
>
> do_compile_prepend_class-target () {
> make CC="${BUILD_CC}" LDFLAGS="${BUILD_LDFLAGS}" -C
> ${B}/tests gen-all-unicode
> }
>
> Which makes it build tests/gen-all-unicode using BUILD_CC (host
> compiler, not cross compiler) for target builds before it goes and
> builds the rest of the project.
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] native recipe question

[Damien LEFEVRE]

OK I got it now. Thanks!

On Tue, May 22, 2018 at 2:00 PM, Burton, Ross  wrote:

> On 22 May 2018 at 11:56, Damien LEFEVRE  wrote:
> > The recipe builds. When I try using with  DEPENDS += "arrayfire-native"
> in
> > the arrayfire recipe I get this warning:
> > WARNING: arrayfire-3.6.0-r0 do_prepare_recipe_sysroot: Manifest
> > /home/damien/pyro/build-jetson-tx2/tmp/sstate-control/
> manifest-x86_64-arrayfire-native.populate_sysroot
> > not found?
>
> Don't call the recipe arrayfire-native and then BBCLASSEXTEND=native,
> as you'll end up with a non-native arrayfile-native and a native
> arrayfire-native-native...
>
> Either have a minimal arrayfire-native recipe which inherits native
> and just builds the piece you want, or do the prepend in the recipe as
> I said.
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Image specific configuration files

[Damien LEFEVRE]

Hi,

For the same MACHINE I create the following images:
- myimage-production
- myimage-rnd
- myimage-retail

The production one has production assisted tools for flashing peripheral
HW, testing vital HW components, writing some serial numbers, etc.

The rnd one has more packages than the retail one just to help rnd work and
debugging in device, but none of the rnd image extra packages.

The retail one has the final product image.

I'm using web and FTP servers. I would like for the rnd version of the
image to have a different nginx configuration to set the root directory to
a development folder, or set an alias.

Furthermore, I'll have different variant of the device where only the
device SW changes but the platform is identical. So I'll end up with
- myimage2-production
- myimage2-rnd
- myimage2-retail

I know how to make MACHINE based configuration. How could I do this in
my nginx.bbappend based on image name?

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

Re: [yocto] Image specific configuration files

[Damien LEFEVRE]

Thanks a lot everyone, this is very helpful =)

On Fri, Jun 1, 2018 at 2:14 PM, Iván Castell 
wrote:

>
>
> 2018-06-01 11:24 GMT+02:00 Alexander Kanavin :
>
>> I have to say defining multiple distros and then tweaking recipes
>> according to those definitions is not a good practice, as recipes should
>> generally only access DISTRO_FEATURES and otherwise be distro-agnostic. The
>> above iptables scenario should be handled with different image recipes,
>> which pull in (via packages) or create different configurations.
>>
>
>
> That has sense. We will refactorize our Yocto repo as suggested. Always
> very helpfull with all your comments Mr Alexander. Thank you very much! :)
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] bbappend extra SRC_URI ignored

[Damien LEFEVRE]

HI,

I'm working on meta-tegra layer and I'd like to append a recipe. The
original recipe looks like this:
https://github.com/madisongh/meta-tegra/blob/rocko-l4t-r28.2/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bb


I've made a tegra-tools_28.2.0.bbappend to change the default PM_CONFIG
DEFAULT from 2 to 3 to get max performance in nvpmodel.conf configuration
file.

```
FILESEXTRAPATHS_prepend := "${THISDIR}/files/tegra186:"
SRC_URI_prepend_tegra186 += "file://nvpmodel.conf "

do_install_append_tegra186() {
install -d ${D}${sysconfdir}
install -m 0755 ${B}/usr/sbin/nvpmodel ${D}${sbindir}/
install -m 0644 ${WORKDIR}/nvpmodel.conf ${D}${sysconfdir}/nvpmodel.conf
install -d ${D}${sysconfdir}/init.d
install -m 0644 ${S}/nvpmodel.init ${D}${sysconfdir}/init.d/nvpmodel
install -d ${D}${systemd_system_unitdir}
install -m 0644 ${S}/nvpmodel.service ${D}${systemd_system_unitdir}
}
```
Would you have any idea why the nvpmodel.conf prepend is ignored and the
file never ends up in ${WORKDIR}.

I've made sure the paths are correct. nvpmodel.conf exists and if I put a
typo like nvpmodel.conf_blabla bitbake throws a warning that it cannot find
the file. So I'm sure the file is found but somehow bitbake ignores it.

I'm having this issue with this one single recipe only, none of the others
in my build system so I'm a bit puzzled.

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

Re: [yocto] bbappend extra SRC_URI ignored

[Damien LEFEVRE]

Typo sorry.

I've tried all possible combination

   - SRC_URI += "file://nvpmodel.conf"
   - SRC_URI_append = " file://nvpmodel.conf"
   - SRC_URI_prepend = "file://nvpmodel.conf "
   - SRC_URI_append_tegra186 = " file://nvpmodel.conf"
   - SRC_URI_prepend_tegra186 = "file://nvpmodel.conf "


-Damien

On Thu, Jun 14, 2018 at 3:24 PM, Robert P. J. Day 
wrote:

> On Thu, 14 Jun 2018, Damien LEFEVRE wrote:
>
> > HI,
> > I'm working on meta-tegra layer and I'd like to append a recipe. The
> original recipe looks like
> > this:
> > https://github.com/madisongh/meta-tegra/blob/rocko-l4t-r28.
> 2/recipes-bsp/tegra-binaries/tegra-t
> > ools_28.2.0.bb
> >
> > I've made a tegra-tools_28.2.0.bbappend to change the default PM_CONFIG
> DEFAULT from 2 to 3 to
> > get max performance in nvpmodel.conf configuration file.
> >
> > ```
> > FILESEXTRAPATHS_prepend := "${THISDIR}/files/tegra186:"
> > SRC_URI_prepend_tegra186 += "file://nvpmodel.conf "
>
>   why are you using both a prepend and the "+=" operator on the same
> line?
>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
>   http://crashcourse.ca/dokuwiki
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] bbappend extra SRC_URI ignored

[Damien LEFEVRE]

Thanks

Here are some interesting parts of bitbake -e. It seems my syntax is
correct


# $FILESEXTRAPATHS [3 operations]
#   set? /home/damien/procbox-pyro/sources/poky/meta/conf/bitbake.conf:325
# "__default:"
#   set
/home/damien/procbox-pyro/sources/poky/meta/conf/documentation.conf:173
# [doc] "Extends the search path the OpenEmbedded build system uses
when looking for files and patches as it processes recipes and append
files."
#   _prepend[tegra186]
/home/damien/procbox-pyro/sources/meta-procbox/meta-tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bbappend:1
#
 
"/home/damien/procbox-pyro/sources/meta-procbox/meta-tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0/tegra186:"
# pre-expansion value:
#
"/home/damien/procbox-pyro/sources/meta-procbox/meta-tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0/tegra186
:__default:"
FILESEXTRAPATHS="
/home/damien/procbox-pyro/sources/meta-procbox/meta-tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0/tegra186
:__default:"

#
# $SRC_URI [10 operations]
.
# "file://nvcamera-daemon.init file://nvcamera-daemon.service
   file://argus-daemon.init file://argus-daemon.service
 file://nvstartup.init file://nvstartup.service "
#   _append[tegra186]
/home/damien/procbox-pyro/sources/meta-tegra/recipes-bsp/tegra-binaries/tegra-binaries-28.2.0.inc:19
# " file://tegra186-flash-helper.sh file://nvpmodel.init
 file://nvpmodel.service "
#   set
/home/damien/procbox-pyro/sources/meta-tegra/recipes-bsp/tegra-binaries/tegra-shared-binaries.inc:8
# ""
#   _prepend[tegra186]
/home/damien/procbox-pyro/sources/meta-procbox/meta-tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bbappend:2
# "file://nvpmodel.conf "
#   set tegra-binaries-28.2.0.inc:42
[__anon_46__home_damien_procbox_pyro_sources_meta_tegra_recipes_bsp_tegra_binaries_tegra_binaries_28_2_0_inc]
# [md5sum] "22bbd0002db06bb26bf5de2d17cea8eb"
#   set tegra-binaries-28.2.0.inc:43
[__anon_46__home_damien_procbox_pyro_sources_meta_tegra_recipes_bsp_tegra_binaries_tegra_binaries_28_2_0_inc]
# [sha256sum]
"62f57b4c03fedde1fe0a1635bd0828b334308eca71bd21f25ae5757f48fb3a76"
# pre-expansion value:
#   "file://nvpmodel.conf  file://tegra186-flash-helper.sh
 file://nvpmodel.init file://nvpmodel.service "
SRC_URI="file://nvpmodel.conf  file://tegra186-flash-helper.sh
 file://nvpmodel.init file://nvpmodel.service "

Then no other mentions until the do_install

Yet the nvpmodel.conf is never copied to ${WORKDIR} which
is 
/home/damien/procbox-pyro/build-jetson-tx2/tmp/work/aarch64_tegra186-poky-linux/tegra-tools/28.2.0-r0
in my case.

Could some bitbake options disable this standard behavior?

On Thu, Jun 14, 2018 at 3:33 PM, Martin Jansa 
wrote:

> On Thu, Jun 14, 2018 at 03:16:00PM +0300, Damien LEFEVRE wrote:
> > HI,
> >
> > I'm working on meta-tegra layer and I'd like to append a recipe. The
> > original recipe looks like this:
> > https://github.com/madisongh/meta-tegra/blob/rocko-l4t-r28.
> 2/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bb
> > <https://github.com/madisongh/meta-tegra/blob/rocko-l4t-r28.
> 2/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bb>
> >
> > I've made a tegra-tools_28.2.0.bbappend to change the default PM_CONFIG
> > DEFAULT from 2 to 3 to get max performance in nvpmodel.conf configuration
> > file.
> >
> > ```
> > FILESEXTRAPATHS_prepend := "${THISDIR}/files/tegra186:"
> > SRC_URI_prepend_tegra186 += "file://nvpmodel.conf "
> >
> > do_install_append_tegra186() {
> > install -d ${D}${sysconfdir}
> > install -m 0755 ${B}/usr/sbin/nvpmodel ${D}${sbindir}/
> > install -m 0644 ${WORKDIR}/nvpmodel.conf ${D}${sysconfdir}/nvpmodel.
> conf
> > install -d ${D}${sysconfdir}/init.d
> > install -m 0644 ${S}/nvpmodel.init ${D}${sysconfdir}/init.d/nvpmodel
> > install -d ${D}${systemd_system_unitdir}
> > install -m 0644 ${S}/nvpmodel.service ${D}${systemd_system_unitdir}
> > }
> > ```
> > Would you have any idea why the nvpmodel.conf prepend is ignored and the
> > file never ends up in ${WORKDIR}.
> >
> > I've made sure the paths are correct. nvpmodel.conf exists and if I put a
> > typo like nvpmodel.conf_blabla bitbake throws a warning that it cannot
> find
> > the file. So I'm sure the file is found but somehow bitbake ignores it.
> >
> > I'm having this issue with this one single recipe only, none of the
> others
> > in my build system so I'm a bit puzzled.
>
> Always use bitbake -e to verify that the file://nvpmodel.conf ends where
> you expect it to end (and if it doesn't the history will show you why
> not).
>
> >
> > Thanks,
> > -Damien
>
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
>
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] bbappend extra SRC_URI ignored

[Damien LEFEVRE]

It's exactly as you said. Thanks a lot!

I got it solved and learned some new tricks =)

-Damien

On Thu, Jun 14, 2018 at 5:23 PM, Martin Jansa 
wrote:

> See ./recipes-bsp/tegra-binaries/tegra-shared-binaries.inc
>
> It's disabling standard do_fetch, do_unpack, do_patch and replacing them
> with tegra-binaries:do_unpack tegra-binaries:do_preconfigure which
> populates
> S directory in work-shared
> S = "${TMPDIR}/work-shared/L4T-${SOC_FAMILY}-${PV}-${PR}/Linux_for_Tegra"
>
> so basically you need to add it in tegra-binaries recipe (not tegra-tools).
>
> On Thu, Jun 14, 2018 at 3:22 PM Damien LEFEVRE 
> wrote:
>
>>
>> Thanks
>>
>> Here are some interesting parts of bitbake -e. It seems my syntax is
>> correct
>>
>>
>> # $FILESEXTRAPATHS [3 operations]
>> #   set? /home/damien/procbox-pyro/sources/poky/meta/conf/
>> bitbake.conf:325
>> # "__default:"
>> #   set /home/damien/procbox-pyro/sources/poky/meta/conf/
>> documentation.conf:173
>> # [doc] "Extends the search path the OpenEmbedded build system uses
>> when looking for files and patches as it processes recipes and append
>> files."
>> #   _prepend[tegra186] /home/damien/procbox-pyro/
>> sources/meta-procbox/meta-tegra/recipes-bsp/tegra-
>> binaries/tegra-tools_28.2.0.bbappend:1
>> # "/home/damien/procbox-pyro/sources/meta-procbox/meta-
>> tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0/tegra186:"
>> # pre-expansion value:
>> #   "/home/damien/procbox-pyro/sources/meta-procbox/meta-
>> tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0/tegra186:__default:"
>> FILESEXTRAPATHS="/home/damien/procbox-pyro/sources/meta-
>> procbox/meta-tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0/tegra186
>> :__default:"
>>
>> #
>> # $SRC_URI [10 operations]
>> .
>> # "file://nvcamera-daemon.init file://nvcamera-daemon.service
>>file://argus-daemon.init file://argus-daemon.service
>>  file://nvstartup.init file://nvstartup.service "
>> #   _append[tegra186] /home/damien/procbox-pyro/
>> sources/meta-tegra/recipes-bsp/tegra-binaries/tegra-
>> binaries-28.2.0.inc:19
>> # " file://tegra186-flash-helper.sh file://nvpmodel.init
>>  file://nvpmodel.service "
>> #   set /home/damien/procbox-pyro/sources/meta-tegra/recipes-
>> bsp/tegra-binaries/tegra-shared-binaries.inc:8
>> # ""
>> #   _prepend[tegra186] /home/damien/procbox-pyro/
>> sources/meta-procbox/meta-tegra/recipes-bsp/tegra-
>> binaries/tegra-tools_28.2.0.bbappend:2
>> # "file://nvpmodel.conf "
>> #   set tegra-binaries-28.2.0.inc:42 [__anon_46__home_damien_
>> procbox_pyro_sources_meta_tegra_recipes_bsp_tegra_
>> binaries_tegra_binaries_28_2_0_inc]
>> # [md5sum] "22bbd0002db06bb26bf5de2d17cea8eb"
>> #   set tegra-binaries-28.2.0.inc:43 [__anon_46__home_damien_
>> procbox_pyro_sources_meta_tegra_recipes_bsp_tegra_
>> binaries_tegra_binaries_28_2_0_inc]
>> # [sha256sum] "62f57b4c03fedde1fe0a1635bd0828
>> b334308eca71bd21f25ae5757f48fb3a76"
>> # pre-expansion value:
>> #   "file://nvpmodel.conf  file://tegra186-flash-helper.sh
>>  file://nvpmodel.init file://nvpmodel.service "
>> SRC_URI="file://nvpmodel.conf  file://tegra186-flash-helper.sh
>>  file://nvpmodel.init file://nvpmodel.service "
>>
>> Then no other mentions until the do_install
>>
>> Yet the nvpmodel.conf is never copied to ${WORKDIR} which
>> is /home/damien/procbox-pyro/build-jetson-tx2/tmp/work/
>> aarch64_tegra186-poky-linux/tegra-tools/28.2.0-r0 in my case.
>>
>> Could some bitbake options disable this standard behavior?
>>
>> On Thu, Jun 14, 2018 at 3:33 PM, Martin Jansa 
>> wrote:
>>
>>> On Thu, Jun 14, 2018 at 03:16:00PM +0300, Damien LEFEVRE wrote:
>>> > HI,
>>> >
>>> > I'm working on meta-tegra layer and I'd like to append a recipe. The
>>> > original recipe looks like this:
>>> > https://github.com/madisongh/meta-tegra/blob/rocko-l4t-r28.
>>> 2/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bb
>>> > <https://github.com/madisongh/meta-tegra/blob/rocko-l4t-r28.
>>> 2/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bb>
>>> >
>>> > I've made a tegra-tools_28.2.0.bbappend to change the default PM_CONFIG
>>> > DEFAULT from 2 to 3 to get max performance in nvpmodel.conf
>>> configu

[yocto] Adding new machine type with boot2qt

[Damien LEFEVRE]

Hi,

I have been working with the jetson reference board with a NVidia TX2
module. I have completed my image and everything runs as expected on the
reference board.

The final product will run on a different carrier, made by ConnectTech.
http://connecttech.com/product/astro-carrier-for-nvidia-jetson-tx2-tx1/

I got the BSP kernel sources from ConnectTech, patched the linux-tegra
kernel repository and created a new machine: astro-tx2.conf

This new machine is identical to the jetson-tx2 one, but with a different
device tree. This is how it looks:
===
#@TYPE: Machine
#@NAME: Nvidia Astro TX2
#@DESCRIPTION: Nvidia Jetson TX2 on ConnectTech Astro


# Comes from meta-tegra
require conf/machine/include/tegra186.inc

# Comes from boot2qt
DEPLOY_CONF_NAME = "NVIDIA Astro TX2"
include conf/distro/include/jetson.inc

KERNEL_DEVICETREE ?=
"_ddot_/_ddot_/_ddot_/_ddot_/nvidia/platform/t18x/quill/kernel-dts/tegra186-tx2-cti-ASG002-revF+.dtb"

# Original device tree
#KERNEL_DEVICETREE ?=
"_ddot_/_ddot_/_ddot_/_ddot_/nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-p3310-1000-c03-00-base.dtb"


MACHINE_FEATURES += "ext2 ext3 vfat"

UBOOT_MACHINE = "p2771--500_defconfig"

EMMC_SIZE ?= "31276924928"
EMMC_DEVSECT_SIZE ?= "512"
BOOTPART_SIZE ?= "8388608"
BOOTPART_LIMIT ?= "10485760"
ROOTFSPART_SIZE ?= "12884901888"
ODMDATA ?= "0x109"
EMMC_BCT ?= "P3310_A00_8GB_Samsung_8GB_lpddr4_204Mhz_A02_l4t.cfg"
NVIDIA_BOARD ?= "t186ref"
TEGRA186_REDUNDANT_BOOT ?= "0"
PARTITION_LAYOUT_TEMPLATE ?= "flash_l4t_t186.xml"
===


I have setup the new machine, setup oe and baked the same image as with
jetson.
===
export MACHINE=astro-tx2
. setup-environment.sh
bitbake stack-rnd
===

Bitbake fails at the do_image_complete in the do_qbsp_image function:
===
DEBUG: Executing shell function do_qbsp_image
| + do_qbsp_image
| + [ -z stack-rnd-astro-tx2.img stack-rnd-astro-tx2.conf
 stack-rnd-astro-tx2.flasher.tar.gz  ]
| + mkdir -p
/home/damien/stack-astro/build-astro-tx2/tmp/work/aarch64_tegra186-poky-linux/stack-rnd/1.0-r0/stack-rnd-1.0/qbsp
|
| + echo stack-rnd-astro-tx2.img
|
| + awk -F: { print $1 }
|
| + src=stack-rnd-astro-tx2.img
|
| + echo stack-rnd-astro-tx2.img
|
| + awk -F: { print $2 }
|
| + dst=
| + [ -e
/home/damien/stack-astro/build-astro-tx2/tmp/work/aarch64_tegra186-poky-linux/stack-rnd/1.0-r0/deploy-stack-rnd-image-complete/stack-rnd-astro-tx2.img
]
| + [ -e
/home/damien/stack-astro/build-astro-tx2/tmp/deploy/images/astro-tx2/stack-rnd-astro-tx2.img
]
|
| + do_qbsp_image
| + [ -z stack-rnd-astro-tx2.img stack-rnd-astro-tx2.conf
 stack-rnd-astro-tx2.flasher.tar.gz  ]
| + mkdir -p
/home/damien/stack-astro/build-astro-tx2/tmp/work/aarch64_tegra186-poky-linux/stack-rnd/1.0-r0/stack-rnd-1.0/qbsp
| + echo stack-rnd-astro-tx2.img
| + awk -F: { print $1 }
| + src=stack-rnd-astro-tx2.img
| + echo stack-rnd-astro-tx2.img
| + awk -F: { print $2 }
| + dst=
| + [ -e
/home/damien/stack-astro/build-astro-tx2/tmp/work/aarch64_tegra186-poky-linux/stack-rnd/1.0-r0/deploy-stack-rnd-image-complete/stack-rnd-astro-tx2.img
]
| + [ -e
/home/damien/stack-astro/build-astro-tx2/tmp/deploy/images/astro-tx2/stack-rnd-astro-tx2.img
]
===

The function is not lying
/home/damien/stack-astro/build-astro-tx2/tmp/work/aarch64_tegra186-poky-linux/stack-rnd/1.0-r0/deploy-stack-rnd-image-complete/
only has these files:
===
drwxr-xr-x  2 damien damien  4096 Jun 26 10:21 ./
drwxrwxr-x 12 damien damien  4096 Jun 26 10:20 ../
-rw-r--r--  1 damien damien 59261 Jun 26 10:20
stack-rnd-astro-tx2-20180626071846.rootfs.manifest
-rw-r--r--  1 damien damien   124 Jun 26 10:21
stack-rnd-astro-tx2-20180626072124.rootfs.conf
lrwxrwxrwx  1 damien damien48 Jun 26 10:21 stack-rnd-astro-tx2.conf ->
stack-rnd-astro-tx2-20180626072124.rootfs.conf
lrwxrwxrwx  1 damien damien52 Jun 26 10:20 stack-rnd-astro-tx2.manifest
-> stack-rnd-astro-tx2-20180626071846.rootfs.manifest
===

As opposed to the jetson-tx2 machine f

[yocto] preferred version 6.% of gcc-sanitizers not available

[Damien LEFEVRE]

Hi,

I have updated my stack to sumo and the platform image builds fine.

Now I'm adding an application which builds against CUDA 9 and due to some
bugs with gcc 7, gcc 6 is highest supported version. The issues has been
fixed in CUDA 10, but I cannot upgrade at time point of time.

So I went to my distro config and added:
GCCVERSION = "6.%"

Then I noticed that poky sumo removed gcc 5 and 6. So I created and
overwrite layer to add back the older compilers. The layer.conf looks like
this

BBPATH .= ":${LAYERDIR}"
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "stack-core"
BBFILE_PATTERN_stack-core = "^${LAYERDIR}/"
BBFILE_PRIORITY_stack-core = "10"

LAYERDEPENDS_stack-core = "core"

LAYERSERIES_COMPAT_stack-core = "sumo"

Then in meta-stack/poky/meta/recipes-devtools/gcc/ I copied the old
compiler recipes from pyro-17.0.4 tag.

I deleted the cache and temp folder.

After all of this I still get this build message and later the build fails.
NOTE: preferred version 6.% of gcc-sanitizers not available (for item
gcc-sanitizers)
NOTE: versions of gcc-sanitizers available: 7.3.0

What am I missing?

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

[yocto] Replacing a configuration file from another recipe

[Damien LEFEVRE]

Hi,

In our base image we use nginx. I created a nginx.bbappend to add our PHP
configuration in a separated layer.

For a specific variant of the image I need to add an extra bit of nginx
configuration.

I though I could create a new recipe to overwrite nginx.conf and include
that recipe in the variant image definition, but bitbake shouts at me that
I cannot modify a file from another recipe.

If that's the case, is it possible to create image name based bbappend
files? Or do I need to create a separate nginx overwrite layer with higher
priority than the base image nginx.bbappend for that image variant? (I
wouldn't like that)

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

[yocto] PR Service multibranch project

[Damien LEFEVRE]

Hi,

I'm looking at enabling PR Service to auto increment some recipe revision.

On a build server I exposed sstate and downloads folder to use that server
as a mirror. So I'm thinking of putting PR service there.

Few things are unclear to me after reading the doc:

We use repotool to manage our branch configuration for different projects.
These different projects share common repositories

Do I need to run an instance of PR server per project or is the database
shared with multiple projects?

Do I understand correctly that if I turn ON buildhistory, I would be able
to switch my layers branches without bumping the revision if it already
exists in the database?

Is the revision bumping MACHINE dependent?

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

[yocto] Changing HOST_CC_ARCH temporarily in recipe

[Damien LEFEVRE]

Hi,

I have a package which requires to first build a x64 binary which is then
used to compile the target platform binaries.

The way I got away with it was to build that host binary from
do_configure_prepend() and then continue with the build procedure.

I recently upgraded to GCC7 + warrior and now building the host binary
from do_configure_prepend fails due to this error:
testCCompiler.c:1:0: error: bad value (armv8-a+crc) for -march= switch

I figured that the arch switch (building for tegra) is defined
in HOST_CC_ARCH as:
-march=armv8-a+crc -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat
-Wformat-security -Werror=format-security

If I clear HOST_CC_ARCH in my recipe file, do_configure_prepend succeeds
but of course the rest of the build will fail.

So i'm trying to do something like this:
do_configure_prepend(){
export HOST_CC_ARCH_BACKUP="${HOST_CC_ARCH}"
HOST_CC_ARCH=""
echo "HOST_CC_ARCH before cmake: ${HOST_CC_ARCH}"
CC="${BUILD_CC}" CXX="${BUILD_CXX}" CCFLAGS="${BUILD_CFLAGS}"
 CXXFLAGS="${BUILD_CPPFLAGS} -std=c++11" LDFLAGS="${BUILD_LDFLAGS}" cmake
${S}
make
HOST_CC_ARCH="${HOST_CC_ARCH_BACKUP}"
}

There I still get:
HOST_CC_ARCH before cmake:  -march=armv8-a+crc -fstack-protector-strong
 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security

So HOST_CC_ARCH doesn't get updated.

How can I temporarily reset HOST_CC_ARCH?

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

Re: [yocto] Changing HOST_CC_ARCH temporarily in recipe

[Damien LEFEVRE]

Yeah that's true and that's how I fixed it =)

Thanks,
-Damien

On Wed, Sep 18, 2019 at 11:44 AM  wrote:

> Hi,
>
> On Wed, Sep 18, 2019 at 11:26:29AM +0300, Damien LEFEVRE wrote:
> > Hi,
> >
> > I have a package which requires to first build a x64 binary which is then
> > used to compile the target platform binaries.
> >
> > The way I got away with it was to build that host binary from
> > do_configure_prepend() and then continue with the build procedure.
> >
> > I recently upgraded to GCC7 + warrior and now building the host binary
> > from do_configure_prepend fails due to this error:
> > testCCompiler.c:1:0: error: bad value (armv8-a+crc) for -march= switch
> >
> > I figured that the arch switch (building for tegra) is defined
> > in HOST_CC_ARCH as:
> > -march=armv8-a+crc -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat
> > -Wformat-security -Werror=format-security
> >
> > If I clear HOST_CC_ARCH in my recipe file, do_configure_prepend succeeds
> > but of course the rest of the build will fail.
> >
> > So i'm trying to do something like this:
> > do_configure_prepend(){
> > export HOST_CC_ARCH_BACKUP="${HOST_CC_ARCH}"
> > HOST_CC_ARCH=""
> > echo "HOST_CC_ARCH before cmake: ${HOST_CC_ARCH}"
> > CC="${BUILD_CC}" CXX="${BUILD_CXX}" CCFLAGS="${BUILD_CFLAGS}"
> >  CXXFLAGS="${BUILD_CPPFLAGS} -std=c++11" LDFLAGS="${BUILD_LDFLAGS}" cmake
> > ${S}
> > make
> > HOST_CC_ARCH="${HOST_CC_ARCH_BACKUP}"
> > }
> >
> > There I still get:
> > HOST_CC_ARCH before cmake:  -march=armv8-a+crc -fstack-protector-strong
> >  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
> >
> > So HOST_CC_ARCH doesn't get updated.
> >
> > How can I temporarily reset HOST_CC_ARCH?
>
> Only clean way to do this is to split the recipe into two parts:
>
>  * native for the build time tooling
>
>  * target for the target only build, which depends on the native build
>time tooling
>
> Everything else is a hack :)
>
> Hope this helps,
>
> -Mikko
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Nothing PROVIDES 'python3-dev'

[Damien LEFEVRE]

Hi,

Migrating from poky:pyro to poky:warrior.

It looks like the python3-dev package is generated from
python3-manifest.json:

"dev": {
"cached": [],
"files": [
"${base_libdir}/*.a",
"${base_libdir}/*.o",
"${bindir}/python*-config",
"${datadir}/aclocal",
"${datadir}/pkgconfig",
"${includedir}",
"${libdir}/*.a",
"${libdir}/*.la",
"${libdir}/*.o",
"${libdir}/lib*${SOLIBSDEV}",
"${libdir}/pkgconfig"
],
"rdepends": [
"core"
],
"summary": "Python development package"
},

and this is used in python3_3.7.2.bb.

Still I get this error: Nothing PROVIDES 'python3-dev'

python3 built successfully.

Any idea?

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

Re: [yocto] Nothing PROVIDES 'python3-dev'

[Damien LEFEVRE]

> On 24/09/2019 10:36, Damien LEFEVRE wrote:
> > Hi,
> >
> > Migrating from poky:pyro to poky:warrior.
> >
> > It looks like the python3-dev package is generated from
> > python3-manifest.json:
> >
> >  ? ? "dev": {
> >  ? ? ? ? "cached": [],
> >  ? ? ? ? "files": [
> >  ? ? ? ? ? ? "${base_libdir}/*.a",
> >  ? ? ? ? ? ? "${base_libdir}/*.o",
> >  ? ? ? ? ? ? "${bindir}/python*-config",
> >  ? ? ? ? ? ? "${datadir}/aclocal",
> >  ? ? ? ? ? ? "${datadir}/pkgconfig",
> >  ? ? ? ? ? ? "${includedir}",
> >  ? ? ? ? ? ? "${libdir}/*.a",
> >  ? ? ? ? ? ? "${libdir}/*.la",
> >  ? ? ? ? ? ? "${libdir}/*.o",
> >  ? ? ? ? ? ? "${libdir}/lib*${SOLIBSDEV}",
> >  ? ? ? ? ? ? "${libdir}/pkgconfig"
> >  ? ? ? ? ],
> >  ? ? ? ? "rdepends": [
> >  ? ? ? ? ? ? "core"
> >  ? ? ? ? ],
> >  ? ? ? ? "summary": "Python development package"
> >  ? ? },
> >
> > and this is used in python3_3.7.2.bb <http://python3_3.7.2.bb>.
> >
> > Still I get this error: Nothing PROVIDES 'python3-dev'
>
> Are you trying to 'bitbake python3-dev'?  You bitbake a recipe, not a
> package, so 'bitbake python3'.
>
> Ross

Hi Ross,

The issue is with the python3 recipe. It declares RDEPENDS_python3-dev, not
DEPENDS_python3-dev.

I'm using the Python C API. So I need headers and so lib files at build
time but only so lib at runtime.

I can add python3-dev to my recipe's RDEPENDS list, but bitbake rightfully
complains about installing -dev files to the image.

I'll check today how to fix that.

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

Re: [yocto] Nothing PROVIDES 'python3-dev'

[Damien LEFEVRE]

Kiitos Jussi!

That solved it.

I had DEPENDS += "python3-dev" and RDEPENDS += "libpython3"

now

I have DEPENDS += "python3" and RDEPENDS += "libpython3"

I'll check if libpython3 is implicit when the image builds.

Cheers,
-Damien

On Wed, Sep 25, 2019 at 10:00 AM Jussi Kukkonen  wrote:

>
>
> On Wed, 25 Sep 2019 at 09:16, Damien LEFEVRE  wrote:
>
>> > On 24/09/2019 10:36, Damien LEFEVRE wrote:
>> > > Hi,
>> > >
>> > > Migrating from poky:pyro to poky:warrior.
>> > >
>> > > It looks like the python3-dev package is generated from
>> > > python3-manifest.json:
>> > >
>> > >  ? ? "dev": {
>> > >  ? ? ? ? "cached": [],
>> > >  ? ? ? ? "files": [
>> > >  ? ? ? ? ? ? "${base_libdir}/*.a",
>> > >  ? ? ? ? ? ? "${base_libdir}/*.o",
>> > >  ? ? ? ? ? ? "${bindir}/python*-config",
>> > >  ? ? ? ? ? ? "${datadir}/aclocal",
>> > >  ? ? ? ? ? ? "${datadir}/pkgconfig",
>> > >  ? ? ? ? ? ? "${includedir}",
>> > >  ? ? ? ? ? ? "${libdir}/*.a",
>> > >  ? ? ? ? ? ? "${libdir}/*.la",
>> > >  ? ? ? ? ? ? "${libdir}/*.o",
>> > >  ? ? ? ? ? ? "${libdir}/lib*${SOLIBSDEV}",
>> > >  ? ? ? ? ? ? "${libdir}/pkgconfig"
>> > >  ? ? ? ? ],
>> > >  ? ? ? ? "rdepends": [
>> > >  ? ? ? ? ? ? "core"
>> > >  ? ? ? ? ],
>> > >  ? ? ? ? "summary": "Python development package"
>> > >  ? ? },
>> > >
>> > > and this is used in python3_3.7.2.bb <http://python3_3.7.2.bb>.
>> > >
>> > > Still I get this error: Nothing PROVIDES 'python3-dev'
>> >
>> > Are you trying to 'bitbake python3-dev'?  You bitbake a recipe, not a
>> > package, so 'bitbake python3'.
>> >
>> > Ross
>>
>> Hi Ross,
>>
>> The issue is with the python3 recipe. It declares RDEPENDS_python3-dev,
>> not DEPENDS_python3-dev.
>>
>
>> I'm using the Python C API. So I need headers and so lib files at build
>> time but only so lib at runtime.
>>
>
> DEPENDing on python3 should give you the former (headers etc in sysroot at
> build time) and RDEPENDing on the correct package (maybe libpython3?)
> should give you the latter -- but RDEPENDS should be automatic if your app
> links to the library.
>
> Is this not working?
>
>
>
>>
>> I can add python3-dev to my recipe's RDEPENDS list, but bitbake
>> rightfully complains about installing -dev files to the image.
>>
>> I'll check today how to fix that.
>>
>> -Damien
>> --
>> ___
>> 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] do_fetch_append: syntax error

[Damien LEFEVRE]

Hi,

I have the following bbappend

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += " \
file://tegra186_cti_defconfig \
"

do_fetch_append(){
mv ${WORKDIR}/tegra186_cti_defconfig ${WORKDIR}/defconfig
}

For this I get an error:
  File "autogenerated", line 3
mv ${WORKDIR}/tegra186_cti_defconfig ${WORKDIR}/defconfig
  ^
SyntaxError: invalid syntax

Can someone explain why? I get the same in do_fetch_append. Starts working
with do_configure_append but that's too late in case of rebuild.

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

Re: [yocto] do_fetch_append: syntax error

[Damien LEFEVRE]

OK understood!

I'll find another way.

Thanks,
-Damien

On Tue, Oct 1, 2019 at 12:13 PM Martin Jansa  wrote:

> On Tue, Oct 01, 2019 at 11:35:21AM +0300, Damien LEFEVRE wrote:
> > Hi,
> >
> > I have the following bbappend
> >
> > FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> > SRC_URI += " \
> > file://tegra186_cti_defconfig \
> > "
> >
> > do_fetch_append(){
> > mv ${WORKDIR}/tegra186_cti_defconfig ${WORKDIR}/defconfig
> > }
> >
> > For this I get an error:
> >   File "autogenerated", line 3
> > mv ${WORKDIR}/tegra186_cti_defconfig ${WORKDIR}/defconfig
> >   ^
> > SyntaxError: invalid syntax
> >
> > Can someone explain why? I get the same in do_fetch_append. Starts
> working
> > with do_configure_append but that's too late in case of rebuild.
>
> do_fetch is python task, you cannot append shell code to it.
>
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto