Re: [yocto] cannelloni.bb (Was: [Chicken and Egg problem] Defining RDEPENDS of the package itself)
Since no reply for socket-can strategy... I long time ago created one for by me and my needs. But still... Here is something worth nothing, if anybody considers socket-can domain! https://github.com/ZoranStojsavljevic/meta-socketcan Best Regards, Zoran Stojsavljevic ___ On Thu, Jul 19, 2018 at 2:51 PM Gunnar Andersson wrote: > > On Thu, 2018-07-19 at 14:44 +0200, Zoran Stojsavljevic wrote: > > Actually, I ran into this: > > http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes- > > extended/socketcan > > :-) I mentioned that in my original response. > > > > > So here, I think, can-utils recipes should be revisited, cannelloni > > recipe added, and also another application recipe added as well: > > https://github.com/dschanoeh/socketcand/ > > Great, you're answering some of the follow-up questions I had. I need to > task switch now, but I will finish up that response later anyway so we can > figure out a good strategy together. > > - Gunnar > > -- > Gunnar Andersson > Development Lead > GENIVI Alliance > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] cannelloni.bb (Was: [Chicken and Egg problem] Defining RDEPENDS of the package itself)
Thanks very much for the information, Zoran! And sorry I forgot to return to this issue before. Best Regards, Gunnar On February 1, 2019 9:32:02 AM GMT+01:00, Zoran Stojsavljevic wrote: >Since no reply for socket-can strategy... I long time ago created one >for by me and my needs. > >But still... Here is something worth nothing, if anybody considers >socket-can domain! > >https://github.com/ZoranStojsavljevic/meta-socketcan > >Best Regards, >Zoran Stojsavljevic >___ > > >On Thu, Jul 19, 2018 at 2:51 PM Gunnar Andersson > wrote: >> >> On Thu, 2018-07-19 at 14:44 +0200, Zoran Stojsavljevic wrote: >> > Actually, I ran into this: >> > >http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes- >> > extended/socketcan >> >> :-) I mentioned that in my original response. >> >> > >> > So here, I think, can-utils recipes should be revisited, cannelloni >> > recipe added, and also another application recipe added as well: >> > https://github.com/dschanoeh/socketcand/ >> >> Great, you're answering some of the follow-up questions I had. I >need to >> task switch now, but I will finish up that response later anyway so >we can >> figure out a good strategy together. >> >> - Gunnar >> >> -- >> Gunnar Andersson >> Development Lead >> GENIVI Alliance >> -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] SDK install w/ CMake
Hello,
we have got the problem that w/ the Yocto recipe and CMake install
targets as below always everything (headers and library or binary
respectively) is installed in the SDK.
The binary also goes into the SDK even though we just add it to
IMAGE_INSTALL based on a XILINX yocto build (rel-v2018.3).
For sure we only want headers to be installed when "-dev"
is added to TOOLCHAIN_TARGET_TASK_append and the binary should not be
installed at all when it is just added to IMAGE_INSTALL.
For sure we studied Yocto and CMake recipes from other libraries where
it works like pugixml but weren't able to figure out what's going wrong.
Yocto recipe
DESCRIPTION = "C++ reflection library"
SECTION = "libs"
LICENSE = "CLOSED"
SRCREV = "${AUTOREV}"
SRCBRANCH = "next"
SRC_URI =
"git://gitlab.company.de/psg/${PN}.git;branch=${SRCBRANCH};protocol=ssh"
DEPENDS = "catch2"
inherit cmake
S = "${WORKDIR}/git"
FILES_${PN}-dev += "${libdir}/cmake"
# The following are needed because the library is unversioned.
# See
https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries#Non-versioned_Libraries
SOLIBS = ".so"
FILES_SOLIBSDEV = ""
CMake library install part
==
# Shared client library target.
add_library(shared SHARED $)
target_include_directories(shared PUBLIC
$
$
)
set_target_properties(shared
PROPERTIES
ARCHIVE_OUTPUT_DIRECTORY lib/shared
LIBRARY_OUTPUT_DIRECTORY lib/shared
RUNTIME_OUTPUT_DIRECTORY lib/shared
OUTPUT_NAME ${LIBRARY_NAME}
)
# Install target.
install(TARGETS shared static
EXPORT ${LIBRARY_NAME}-config
DESTINATION ${CMAKE_INSTALL_LIBDIR})
install(DIRECTORY include/reflect DESTINATION
${CMAKE_INSTALL_INCLUDEDIR})
install(EXPORT ${LIBRARY_NAME}-config
NAMESPACE ${LIBRARY_NAME}-
DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/${LIBRARY_NAME})
CMake binary install part
=
install(TARGETS ${EXECUTABLE_NAME} DESTINATION ${CMAKE_INSTALL_BINDIR})
Many thanks for any hints
Eric
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Error function "license_create_manifest"
Hi
I'm trying to build for an imx6 board with krogoth (I can't use newer vesion),
but i got an error during do_rootfs step. I'm triyng since 3 days to fix but
with no result.
Here the error :
Build Configuration:
BB_VERSION= "1.30.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "Debian-9.7"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE = "imx6qdl-iwg15-q7"
DISTRO= "fsl-imx-x11"
DISTRO_VERSION= "4.1.15-2.1.0"
TUNE_FEATURES = "arm armv7a vfp neoncallconvention-hard
cortexa9"
TARGET_FPU= "hard"
meta
meta-poky = "HEAD:f5da2a5913319ad6ac2141438ba1aa17576326ab"
meta-oe
meta-multimedia = "HEAD:247b1267bbe95719cd4877d2d3cfbaf2a2f4865a"
meta-fsl-arm = "HEAD:be78894e4682f111575470fb23e51e6ba523508d"
meta-fsl-arm-extra = "HEAD:3dfb82fc7e703eae9891b3ffda0e9393701f2396"
meta-fsl-demos= "HEAD:a165068f8a0d1cf29aabe4b4053f28be1c2aa492"
meta-bsp
meta-sdk = "HEAD:823b26a67261270d2bf22d511e6190641a8a90cf"
meta-browser = "HEAD:77736988073a5d90fcff9d0005c8477332ede387"
meta-gnome
meta-networking
meta-python
meta-filesystems = "HEAD:247b1267bbe95719cd4877d2d3cfbaf2a2f4865a"
meta-qt5 = "HEAD:ccae79be69c5268df3b47e4e14cea0591c39a531"
NOTE: Preparing RunQueue
WARNING:
virtual:native:/home/aplug/iwg15-release-bsp/sources/poky/meta/recipes-support/lzop/lzop_1.03.bb.do_build
is tainted from a forced run
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
No currently running tasks (6643 of 8040)
No real function for mknod:
/home/aplug/iwg15-release-bsp/build_iwg15/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64/libpseudo.so:
undefined symbol: mknod
No real function for mknodat:
/home/aplug/iwg15-release-bsp/build_iwg15/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64/libpseudo.so:
undefined symbol: mknodat
No real function for mknod:
/home/aplug/iwg15-release-bsp/build_iwg15/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64/libpseudo.so:
undefined symbol: mknod
No real function for mknodat:
/home/aplug/iwg15-release-bsp/build_iwg15/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64/libpseudo.so:
undefinCurrently
1 running tasks (6643 of 8040):
0: fsl-image-gui-1.0-r0 do_rootfs (pid 5919)
ERROR: fsl-image-gui-1.0-r0 do_rootfs: Error executing a python function in
exec_python_func() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function:
0001:
*** 0002:license_create_manifest(d)
0003:
File:
'/home/aplug/iwg15-release-bsp/sources/poky/meta/classes/license.bbclass',
lineno: 48, function: license_create_manifest
0044:pkg_dic = {}
0045:for pkg in sorted(image_list_installed_packages(d)):
0046:pkg_info = os.path.join(d.getVar('PKGDATA_DIR', True),
0047:'runtime-reverse', pkg)
*** 0048:pkg_name = os.path.basename(os.readlink(pkg_info))
0049:
0050:pkg_dic[pkg_name] = oe.packagedata.read_pkgdatafile(pkg_info)
0051:if not "LICENSE" in pkg_dic[pkg_name].keys():
0052:pkg_lic_name = "LICENSE_" + pkg_name
Exception: OSError: [Errno 2] No such file or directory:
'/home/aplug/iwg15-release-bsp/build_iwg15/tmp/sysroots/imx6qdl-iwg15-q7/pkgdata/runtime-reverse/No'
ERROR: fsl-image-gui-1.0-r0 do_rootfs: Function failed: license_create_manifest
ERROR: Logfile of failure stored in:
/home/aplug/iwg15-release-bsp/build_iwg15/tmp/work/imx6qdl_iwg15_q7-poky-linux-gnueabi/fsl-image-gui/1.0-r0/temp/log.do_rootfs.5919
ERROR: Task 9
(/home/aplug/iwg15-release-bsp/sources/meta-fsl-bsp-release/imx/meta-sdk/recipes-fsl/images/fsl-image-gui.bb,
do_rootfs) failed with exit code '1'
Thomas DRUILHE
The information in this e-mail is confidential. The contents may not be
disclosed or used by anyone other than the addressee. Access to this e-mail by
anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and
delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of
this e-mail as it has been sent over public networks. If you have any concerns
over the content of this message or its Accuracy or Integrity, please contact
Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus
scanning software but you should take whatever measures you deem to be
appropriate to ensure that this message and any attachments are virus free.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] Rainbow screen with Raspberry Pi 3 A+ but not on B+
Hi! I have been running a yocto image (sumo) on a raspberry 3 B+ without any problems, but wanted to test the new raspberry Pi 3 A+ board with it but I just get the Rainbow screen on boot. I have updated meta-openembedded to the latest sumo and meta-raspberry was still up to date with the latest (sumo) and still the same result. My question: Has anybody been running sumo on a raspberrypi 3 a+ successfully? I have been googling around for issues but can't find anything on the new board and yocto. Seems that I am missing something. Regards, Markus -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Rainbow screen with Raspberry Pi 3 A+ but not on B+
On Fri, Feb 1, 2019 at 1:11 PM Markus W wrote: > Hi! > > I have been running a yocto image (sumo) on a raspberry 3 B+ without any > problems, but wanted to test the new raspberry Pi 3 A+ board with it but I > just get the Rainbow screen on boot. I have updated meta-openembedded to > the latest sumo and meta-raspberry was still up to date with the latest > (sumo) and still the same result. > > My question: Has anybody been running sumo on a raspberrypi 3 a+ > successfully? I have been googling around for issues but can't find > anything on the new board and yocto. Seems that I am missing something. > Can you connect serial console and add enable_uart=1 to config.txt and verify? This looks like it doesn't boot. You can also ask on [1] > > Regards, > Markus > -- > [1] - https://github.com/agherzan/meta-raspberrypi/issues BR, marek > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Rainbow screen with Raspberry Pi 3 A+ but not on B+
Thanks Marek! I pretty sure it doesn't boot, but I haven't confirmed it as you suggested it. I have never connected to the uart interface directly on the GPIO or via bluetooth. It probably takes me more time to figure it out and to do this than trying the thud branch as @agherzan has mentioned here: https://github.com/agherzan/meta-raspberrypi/issues/373 I am also using meta-mender, do I need to upgrade all layers to thud than? Regards, Markus On Fri, 1 Feb 2019 at 13:17, Belisko Marek wrote: > On Fri, Feb 1, 2019 at 1:11 PM Markus W wrote: > >> Hi! >> >> I have been running a yocto image (sumo) on a raspberry 3 B+ without any >> problems, but wanted to test the new raspberry Pi 3 A+ board with it but I >> just get the Rainbow screen on boot. I have updated meta-openembedded to >> the latest sumo and meta-raspberry was still up to date with the latest >> (sumo) and still the same result. >> > >> My question: Has anybody been running sumo on a raspberrypi 3 a+ >> successfully? I have been googling around for issues but can't find >> anything on the new board and yocto. Seems that I am missing something. >> > Can you connect serial console and add enable_uart=1 to config.txt and > verify? This looks like it doesn't boot. You can also ask on [1] > >> >> Regards, >> Markus >> > -- >> > > [1] - https://github.com/agherzan/meta-raspberrypi/issues > > BR, > > marek > >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto >> > > > -- > as simple and primitive as possible > - > Marek Belisko - OPEN-NANDRA > Freelance Developer > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic > Tel: +421 915 052 184 > skype: marekwhite > twitter: #opennandra > web: http://open-nandra.com > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Help with cleaning/rebuidling
Hi Ed,
I don't want to state the obvious but firstly did you check that you have
the stuff asked :
*CMake Error: The source directory "/mnt/drive/yocto/poky/build/t*
*mp/work/cortexa9-vfp-neon-poky**-linux-gnueabi/mosquitto/1.5.*
*5-r0/mosquitto-1.5.5" does not exist.*
If
/mnt/drive/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.5.5-r0/mosquitto-1.5.5
is not reachable then that's the issue.
Regards,
On Mon, Jan 28, 2019 at 6:19 PM Edward Wingate wrote:
> The first time I did a build, my mosquitto recipe worked. Then I did
> a 'bitbake -ccleanall mosquitto', and now when I do 'bitbake
> mosquitto', I get this error:
>
> 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: Python function autotools_copy_aclocals 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 do_configure
> CMake Error: The source directory
>
> "/mnt/drive/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.5.5-r0/mosquitto-1.5.5"
> does not exist.
> Specify --help for usage, or press the help button on the CMake GUI.
> WARNING: exit code 1 from a shell command.
> ERROR: Function failed: do_configure (log file is located at
>
> /mnt/drive/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.5.5-r0/temp/log.do_configure.37839)
>
> It seems like it doesn't fetch/unpack the source before do_configure.
> I tried to do 'bitbake -c fetch mosquitto' and 'bitbake -c unpack
> mosquitto', and they both say all tasks didn't need to be rerun. I
> forced it by adding '-f', but that didn't help either.
>
> I'm still using jethro and my mosquitto_1.5.5.bb recipe is this:
>
> === BEGIN RECIPE ===
> SUMMARY = "MQTT 3.1 compliant library"
> HOMEPAGE = "https://mosquitto.org";
> MAINTAINER = "Robert Lehmann "
>
> LICENSE = "EPL-1.0"
> LIC_FILES_CHKSUM =
> "file://LICENSE.txt;md5=62ddc846179e908dc0c8efec4a42ef20"
>
> SRC_URI = "https://mosquitto.org/files/source/mosquitto-${PV}.tar.gz";
> SRC_URI[md5sum] = "a17dffc6f63b2a4ab2eb5c51139e60e9"
> SRC_URI[sha256sum] =
> "fcdb47e340864c545146681af7253399cc292e41775afd76400fda5b0d23d668"
>
> DEPENDS = "openssl"
> RDEPENDS_${PN} = "util-linux"
>
> inherit cmake
>
> # Specify any options you want to pass to cmake using EXTRA_OECMAKE:
> EXTRA_OECMAKE = " -DCMAKE_SKIP_RPATH=ON "
> === END RECIPE ===
>
> Can anyone help with this?
>
> Thanks,
> Ed
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
[image: SMILE] [image: Facebook]
[image: LinkedIn]
[image: Github]
[image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Rainbow screen with Raspberry Pi 3 A+ but not on B+
Hi Markus, On Fri, Feb 1, 2019 at 2:54 PM Markus W wrote: > Thanks Marek! > > I pretty sure it doesn't boot, but I haven't confirmed it as you suggested > it. > > I have never connected to the uart interface directly on the GPIO or via > bluetooth. It probably takes me more time to figure it out and to do this > than trying the thud branch as @agherzan has mentioned here: > https://github.com/agherzan/meta-raspberrypi/issues/373 > OK attaching serial port isn't that hard but as you stated, please try thud branch. You can try https://hub.mender.io/t/raspberry-pi-3-model-b-b/57 to follow this procedure as this is verified for B/B+ works fine with thud. > > I am also using meta-mender, do I need to upgrade all layers to thud than? > > Regards, > Markus > > P.S.: pls don't top post ;) marek > > On Fri, 1 Feb 2019 at 13:17, Belisko Marek > wrote: > >> On Fri, Feb 1, 2019 at 1:11 PM Markus W wrote: >> >>> Hi! >>> >>> I have been running a yocto image (sumo) on a raspberry 3 B+ without any >>> problems, but wanted to test the new raspberry Pi 3 A+ board with it but I >>> just get the Rainbow screen on boot. I have updated meta-openembedded to >>> the latest sumo and meta-raspberry was still up to date with the latest >>> (sumo) and still the same result. >>> >> >>> My question: Has anybody been running sumo on a raspberrypi 3 a+ >>> successfully? I have been googling around for issues but can't find >>> anything on the new board and yocto. Seems that I am missing something. >>> >> Can you connect serial console and add enable_uart=1 to config.txt and >> verify? This looks like it doesn't boot. You can also ask on [1] >> >>> >>> Regards, >>> Markus >>> >> -- >>> >> >> [1] - https://github.com/agherzan/meta-raspberrypi/issues >> >> BR, >> >> marek >> >>> ___ >>> yocto mailing list >>> yocto@yoctoproject.org >>> https://lists.yoctoproject.org/listinfo/yocto >>> >> >> >> -- >> as simple and primitive as possible >> - >> Marek Belisko - OPEN-NANDRA >> Freelance Developer >> >> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic >> Tel: +421 915 052 184 >> skype: marekwhite >> twitter: #opennandra >> web: http://open-nandra.com >> > -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Help with cleaning/rebuidling
On Fri, Feb 1, 2019 at 7:57 AM Yann CARDAILLAC
wrote:
> Hi Ed,
>
> I don't want to state the obvious but firstly did you check that you have
> the stuff asked :
>
>
> *CMake Error: The source directory "/mnt/drive/yocto/poky/build/t*
> *mp/work/cortexa9-vfp-neon-poky**-linux-gnueabi/mosquitto/1.5.*
> *5-r0/mosquitto-1.5.5" does not exist.*
>
> If
> /mnt/drive/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.5.5-r0/mosquitto-1.5.5
> is not reachable then that's the issue.
>
>
That directory does not exist. I believe the cleanall removed that
directory. The question is why doesn't bitbake make the directory and
untar into it, like it did the very first time I bitbaked mosquitto? To
work around this, I have to manually untar the mosquitto tarball from my
DL_DIR into that directory, and then mosquitto will build properly.
> Regards,
>
> On Mon, Jan 28, 2019 at 6:19 PM Edward Wingate
> wrote:
>
>> The first time I did a build, my mosquitto recipe worked. Then I did
>> a 'bitbake -ccleanall mosquitto', and now when I do 'bitbake
>> mosquitto', I get this error:
>>
>> 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: Python function autotools_copy_aclocals 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 do_configure
>> CMake Error: The source directory
>>
>> "/mnt/drive/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.5.5-r0/mosquitto-1.5.5"
>> does not exist.
>> Specify --help for usage, or press the help button on the CMake GUI.
>> WARNING: exit code 1 from a shell command.
>> ERROR: Function failed: do_configure (log file is located at
>>
>> /mnt/drive/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.5.5-r0/temp/log.do_configure.37839)
>>
>> It seems like it doesn't fetch/unpack the source before do_configure.
>> I tried to do 'bitbake -c fetch mosquitto' and 'bitbake -c unpack
>> mosquitto', and they both say all tasks didn't need to be rerun. I
>> forced it by adding '-f', but that didn't help either.
>>
>> I'm still using jethro and my mosquitto_1.5.5.bb recipe is this:
>>
>> === BEGIN RECIPE ===
>> SUMMARY = "MQTT 3.1 compliant library"
>> HOMEPAGE = "https://mosquitto.org";
>> MAINTAINER = "Robert Lehmann "
>>
>> LICENSE = "EPL-1.0"
>> LIC_FILES_CHKSUM =
>> "file://LICENSE.txt;md5=62ddc846179e908dc0c8efec4a42ef20"
>>
>> SRC_URI = "https://mosquitto.org/files/source/mosquitto-${PV}.tar.gz";
>> SRC_URI[md5sum] = "a17dffc6f63b2a4ab2eb5c51139e60e9"
>> SRC_URI[sha256sum] =
>> "fcdb47e340864c545146681af7253399cc292e41775afd76400fda5b0d23d668"
>>
>> DEPENDS = "openssl"
>> RDEPENDS_${PN} = "util-linux"
>>
>> inherit cmake
>>
>> # Specify any options you want to pass to cmake using EXTRA_OECMAKE:
>> EXTRA_OECMAKE = " -DCMAKE_SKIP_RPATH=ON "
>> === END RECIPE ===
>>
>> Can anyone help with this?
>>
>> Thanks,
>> Ed
>> --
>> ___
>> 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] RDEPENDS and do_rootfs
Hi, In my case, package A creates groups a1, a2 and a3. B is actually a family of packages B1, B2 and B3 that each create user b1, b2, or b3 respectively, but also adds the new user to groups a1, a2 and/or a3. So in this case, it is necessary that package A first be installed AND that its post-inst scripts have run to generate groups a1, a2 and a3. If, as you suggest, RDEPENDS will NOT guarantee this, then I will need to solve this another way, perhaps by... agroups.bbclass - creates groups a1, a2 and a3 for any package recipe that inherits it. Package recipes, A, B1, B2 and B3 would thus all have to inherit from agroups.bbclass. The first package installed creates the groups in rootfs. The remaining packages just find the groups already present. So I think that there may be a solution for my case. - I think that this limitation possibly may be related to some useradd failures reported a few years back such as "ERROR: Tried running useradd command 10 times without scucess, giving up". There had been changes made by patching the shadow package and by refining the bbclass to use file locks. I went for about three years with just the luck of the draw that packages were installed in a good order until this showed up. I had backported some of these changes to 'daisy' before realizing that the groups simply hadn't been created yet. On Thu, 2019-01-31 at 10:52 +, Burton, Ross wrote: > Forgot to say, Bitbake's dependency model is loosely based on > Debian's > so the Debian Policy is a good read for semantics: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.debian.org%2Fdoc%2Fdebian-policy%2Fch-relationships.html%23binary-dependencies-depends-recommends-suggests-enhances-pre-depends&data=02%7C01%7Cdwatkins%40sierrawireless.com%7Ccb4829af452948bfa95208d6876a34ed%7C08059a4c248643dd89e33a747e0dcbe8%7C1%7C0%7C636845287569900461&sdata=WsJ0EjOAI7C%2BurDmAfVMCGb9SEaAWMxy%2F8Xpfks%2FjPA%3D&reserved=0 > > Debian's "Depends" is our "RDEPENDS", what you want is "Pre-Depends" > that we don't (yet) support. As I said, this is just a matter of > picking a name and then mapping it into the control file. > > Ross > > On Thu, 31 Jan 2019 at 10:49, Burton, Ross > wrote: > > Presumably the problem here is that you've a maintainer script > (preinst or postinst) in B that needs a binary/library from A, and is > failing because B's postinst is running before A is unpacked? If > not, > please clarify, otherwise the problem is that DEPENDS just talks > about > the final solution. If you want to express that A needs to be > installed and configured before B is configured then you'll need to > use Pre-Depends, which I don't believe are actually supported in the > packaging classes yet. I know that dpkg and opkg support this, and > presumably rpm too, so extending the packaging classes is a few > minutes work. > > Ross > > On Thu, 31 Jan 2019 at 06:51, Darcy Watkins < > dwatk...@sierrawireless.com> wrote: > > Hi, > > Can someone knowledgeable with the inner workings of the build system > please confirm... > > IF package B has RDEPENDS on package A > > THEN during do_rootfs task, package A will always be installed into > rootfs first AND the post-inst scripts of package A will always be > run > prior to those for package B. > > Also, if that can be confirmed for 'daisy' branch, that would really > be > helpful. If not, then please mention as far back the branch that you > know for sure. Thanks! > > > > -- > > > Regards, > > Darcy > > Darcy Watkins :: Senior Staff Engineer, Firmware > > SIERRA > WIRELESS > Direct +1 604 233 7989 :: Fax +1 604 231 1109 :: Main + > 1 604 231 1100 > 13811 Wireless Way :: Richmond, BC Canada V6V 3A4 > [P1] > > dwatk...@sierrawireless.com :: > https://na01.safelinks.protection.outlook.com/?url=www.sierrawireless.com&data=02%7C01%7Cdwatkins%40sierrawireless.com%7Ccb4829af452948bfa95208d6876a34ed%7C08059a4c248643dd89e33a747e0dcbe8%7C1%7C0%7C636845287569900461&sdata=d946J0HFRXZgDiC1QjtumL%2BX4mzpHkhlvuC1J1xEbeE%3D&reserved=0 > > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Flistinfo%2Fyocto&data=02%7C01%7Cdwatkins%40sierrawireless.com%7Ccb4829af452948bfa95208d6876a34ed%7C08059a4c248643dd89e33a747e0dcbe8%7C1%7C0%7C636845287569900461&sdata=DiZmJr86q5r0i1iVk4Yraj0CB6fXY0Eczkh8HpigJlA%3D&reserved=0 -- Regards, Darcy Darcy Watkins :: Senior Staff Engineer, Firmware SIERRA WIRELESS Direct +1 604 233 7989 :: Fax +1 604 231 1109 :: Main + 1 604 231 1100 13811 Wireless Way :: Richmond, BC Canada V6V 3A4 [P1] dwatk...@sierrawireless.com :: www.sierrawireless.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
