Hello Alan, I would admit that I did not understand the package you would like to use, and what is the problem with it.
But I, from the back of my mind (somehow) understood that I need to query the packages I know, and these packages are mandatory for any Linux. The following I tried on the host system (which is Fedora 26), transcript follows: [root@192 build]# dnf install systemd Last metadata expiration check: 3:27:32 ago on Fri 10 Nov 2017 11:54:19 AM CET. Package systemd-233-7.fc26.x86_64 is already installed, skipping. Dependencies resolved. Nothing to do. Complete! [root@192 build]# dnf install systemctl Last metadata expiration check: 3:27:43 ago on Fri 10 Nov 2017 11:54:19 AM CET. No match for argument: systemctl Error: Unable to find a match [root@192 build]# which systemd-* /usr/bin/which: no systemd-* in (/home/user/YOCTO/oe_core_embedded/poky/scripts:/home/user/YOCTO/oe_core_embedded/poky/bitbake/bin:/usr/libexec/python2-sphinx:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/user/.local/bin:/home/user/bin) [root@192 build]# which systemd- systemd-analyze systemd-detect-virt systemd-mount systemd-socket-activate systemd-ask-password systemd-escape systemd-notify systemd-stdio-bridge systemd-cat systemd-firstboot systemd-nspawn systemd-sysusers systemd-cgls systemd-hwdb systemd-path systemd-tmpfiles systemd-cgtop systemd-inhibit systemd-resolve systemd-tty-ask-password-agent systemd-delta systemd-machine-id-setup systemd-run systemd-umount [root@192 build]# which systemctl /usr/bin/systemctl [root@192 build]# But, in contrary, using the target YOCTO, despite we have there two packages: */meta/recipes-core/systemd/systemd* *./meta/recipes-core/systemd/systemd-systemctl* I do not see them presented in the final qemux86-64 build. I'll repeat (target CLI transcript follows): sh-4.4# uname -r 4.12.12-yocto-standard sh-4.4# which systemd sh-4.4# which systemctl sh-4.4# Maybe it is me... But I think somebody should look also to what I wrote, since I am, maybe, after all, mistaken!? I really hope I made it very clear. Thank you, Zoran Stojsavljevic On Fri, Nov 10, 2017 at 1:23 PM, Alan Martinovic <alan.martino...@senic.com> wrote: > Hey Zoran, > this doesn't really have anything to do with my question. > Would suggest you to rephrase it to make it more clear. > > But we have there both packages??? We do, we do?! > > Do we really have problem here, YOCTO maintainers??? Please, could you >> post sound and logical explanation for NOT having these services in the >> default YOCTO? > > > Also would suggest you perhaps reiterate on your question style a bit, > it might result in more people responding. > > Be Well, > Alan > > > On Fri, Nov 10, 2017 at 12:41 PM, Zoran Stojsavljevic < > zoran.stojsavlje...@gmail.com> wrote: > >> It is, after all, interesting question, you posted here, Alan! >> >> I did something else, very different than you - I did the following! >> >> [user@192 poky]$ pwd >> /home/user/YOCTO/oe_core_embedded/poky >> [user@192 poky]$ find . -name systemd* >> ./scripts/lib/wic/canned-wks/systemd-bootdisk.wks >> ./meta-yocto-bsp/lib/oeqa/selftest/cases/systemd_boot.py >> ./build/tmp/sysroots-components/core2-64/at-spi2-core/usr/lib/systemd >> ./build/tmp/sysroots-components/core2-64/rpm/usr/lib/rpm-plu >> gins/systemd_inhibit.so >> ./meta/lib/oeqa/runtime/cases/systemd.py >> ./meta/classes/systemd.bbclass >> ./meta/classes/systemd-boot.bbclass >> ./meta/recipes-devtools/systemd-bootchart >> ./meta/recipes-devtools/systemd-bootchart/systemd-bootchart_231.bb >> ./meta/recipes-core/systemd >> ./meta/recipes-core/systemd/systemd_234.bb >> ./meta/recipes-core/systemd/systemd-machine-units_1.0.bb >> ./meta/recipes-core/systemd/systemd-serialgetty >> ./meta/recipes-core/systemd/systemd.inc >> ./meta/recipes-core/systemd/systemd-boot_234.bb >> ./meta/recipes-core/systemd/systemd-compat-units.bb >> ./meta/recipes-core/systemd/systemd-systemctl-native.bb >> ./meta/recipes-core/systemd/systemd >> ./meta/recipes-core/systemd/systemd-systemctl >> ./meta/recipes-core/systemd/systemd-serialgetty.bb >> [user@192 poky]$ >> >> But we have there both packages??? We do, we do?! >> >> *./meta/recipes-core/systemd/systemd* >> *./meta/recipes-core/systemd/systemd-systemctl* >> >> So, systemd is still present as package in basic poky master tree: >> ./meta/recipes-core/systemd/systemd >> ./meta/recipes-core/systemd/systemd-systemctl >> >> And, here are the heads from tree posted from the qemux86-64 target >> (/etc/build/): >> >> ----------------------- >> Build Configuration: | >> ----------------------- >> DISTRO = poky >> DISTRO_VERSION = 2.4 >> ----------------------- >> Layer Revisions: | >> ----------------------- >> meta = rocko:65d23bd7986615fdfb0f1717b615534a2a14ab80 >> -- modified >> meta-poky = rocko:65d23bd7986615fdfb0f1717b615534a2a14ab80 -- >> modified >> meta-yocto-bsp = rocko:65d23bd7986615fdfb0f1717b615534a2a14ab80 -- >> modified >> >> And, when I queried on the QEMU (qemux86-64) target both systemd and >> systemctl, I get nothing (at all), which is VERY strange!? >> Target CLI transcript follows: >> >> sh-4.4# uname -r >> 4.12.12-yocto-standard >> sh-4.4# which systemd >> sh-4.4# which systemctl >> sh-4.4# >> >> Do we really have problem here, YOCTO maintainers??? Please, could you >> post sound and logical explanation for NOT having these services in the >> default YOCTO? >> >> Thank you, >> Zoran >> >> On Fri, Nov 10, 2017 at 11:07 AM, Alan Martinovic < >> alan.martino...@senic.com> wrote: >> >>> Hi, >>> I need to add a systemd service that needs no additional sources >>> compiled, but just needs an available command executed at boot. >>> >>> I've created a basis for the recipe in my layer: >>> >>> nrf52-usb-systemd/ >>> |-- files >>> | `-- btattach-nrf-acm.service >>> `-- nrf52-usb-systemd.bb >>> >>> >>> together with a recipe template (nrf52-usb-systemd.bb) >>> for which I don't know if works yet. >>> >>> SUMMARY = "Writes patterns to the fb device" >>> LICENSE = "MIT" >>> LIC_FILES_CHKSUM = "file://COPYING.MIT;md5=3da9cf >>> bcb788c80a0384361b4de20420" >>> >>> inherit systemd >>> >>> REQUIRED_DISTRO_FEATURES= "systemd" >>> >>> SRC_URI = "file://btattach-nrf-acm.service" >>> >>> do_install () { >>> >>> install -m 0644 ${WORKDIR}/btattach-nrf-acm.service >>> ${D}${sysconfdir}/systemd/system >>> } >>> >>> NATIVE_SYSTEMD_SUPPORT = "1" >>> SYSTEMD_PACKAGES = "${PN}" >>> SYSTEMD_SERVICE_${PN} = "fb-draw.service" >>> >>> >>> I'm not sure I got the install command right and >>> if the service file is making it way to the proper location. >>> >>> Instead of building the whole image, flashing and checking >>> it out, I would like to test how devtool could help here. >>> >>> I execute: >>> >>> devtool build nrf52-usb-systemd >>> >>> this results in a creation of a workspace with the sources files. >>> What I am not seeing is a creation of a device sysroot which would >>> show me that the do_install was correctly written. >>> >>> Given that the device sysroot directory on the host would be called >>> "sysroot" was hoping to be able do confirm that the following took >>> place >>> >>> ${D}${sysconfdir}/systemd/system -> .sysroot/etc/ssytemd/system >>> >>> and confirming there is a >>> >>> .sysroot/etc/ssytemd/system/btattach-nrf-acm.service >>> >>> >>> Is this possible with devtool, or am I misinterpreting >>> what it's purpose is? >>> >>> >>> -- >>> _______________________________________________ >>> yocto mailing list >>> yocto@yoctoproject.org >>> https://lists.yoctoproject.org/listinfo/yocto >>> >>> >> >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto