**** BEGIN LOGGING AT Thu Dec 10 02:59:56 2020
Dec 10 05:43:54 <Hadi> There used to be support  SRC_DIST_LOCAL  to download all the src into deploy/source directory.  I think it is deprecated. Anyone knows the alternative
Dec 10 05:44:15 <Hadi> Here are some info about it http://www.embeddedlinux.org.cn/OEManual/src_uri_variable.html
Dec 10 07:34:06 <mckoan> good morning
Dec 10 07:34:45 <khem> gm mckoan
Dec 10 08:49:48 <LetoThe2nd> yo dudX
Dec 10 08:57:05 <mckoan> hi LetoThe2nd
Dec 10 10:17:51 <loblik> I'm building image for aarch64 SOC which has system controller which is 32bit arm core. I would like to have recipe which builds firmware for the SCU (system controller). Can I somehow specify different toolchain to be used for this recipe?
Dec 10 10:20:03 <qschulz> loblik: if you jsut want a 32b version, you can use multilib and ask for the lib32- package of the system controller firmware
Dec 10 10:20:43 <qschulz> if it's a completely different toolchain, you probably want to have a look at multiconfig with two different machines, one representing the target and the other the system controller
Dec 10 10:26:37 * LetoThe2nd just ordered 3TB pcie nvme for his build machine :)
Dec 10 10:27:09 <LetoThe2nd> fast sstate, yay!
Dec 10 10:27:37 <erbo> nice
Dec 10 10:35:36 <erbo> LetoThe2nd: I remember the first builds I did using openembedded on a budget laptop, must have been 2008 or 2009. I had no idea what I was doing and every iteration took forever.
Dec 10 10:35:53 <erbo> Now I still don't have a clue, but at least building is faster :)
Dec 10 10:36:50 <LetoThe2nd> hehe
Dec 10 10:38:19 <LetoThe2nd> well said box actually performed nicely after purchase in 2015. its a 32way xeon with 128G ram already, so as long as we had less and smaller builds caching would effectively boost builds incredibly for us. nowadays the box is way more loaded, plus the builds are much larger. hence io kicks in badly.
Dec 10 10:46:33 <paulbarker> LetoThe2nd: Now you can break things even faster!
Dec 10 10:50:41 <LetoThe2nd> yeah.
Dec 10 10:54:49 <rburton> loblik: you might want to look at meta-arm, it has recipes and compilers for arm firmware
Dec 10 10:55:34 <rburton> loblik: ideally, multiconfig, but firmware building is sufficiently insane that meta-arm currently just uses standalone compilers
Dec 10 10:57:11 <LetoThe2nd> "firmware building is sufficiently insane" ... awesome quote
Dec 10 10:58:38 <rburton> LetoThe2nd: guess how many hours of my life were wasted writing this comment http://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_1.0.bb#n31
Dec 10 10:59:29 <LetoThe2nd> rburton: i hereby guess: n. with n > 0.
Dec 10 11:15:42 <luneff> hey guys! Any good method of collecting coredumps for Yocto? Like google's breakpad. I see there's an assortment of tools, wondering if there's mainstream
Dec 10 11:16:38 <RP> luneff: we'd love to have something standard but I don't think anyone has put it together yet unfortunately
Dec 10 11:18:38 <LetoThe2nd> luneff: we're using minicoredumper for getting reasonable-sized dumps on the devices, and it works ok for us. but ofc, its not comparable in scope.
Dec 10 11:19:56 <luneff> LetoThe2nd, do you analyze them on the board or you upload it elsewhere against debug syms?
Dec 10 11:20:45 <LetoThe2nd> luneff: the latter. we keep a proper history of deployed versions so we can correlate them
Dec 10 11:21:25 <luneff> lots of code, probably? get syms from yocto build, UI, receiving part...
Dec 10 11:22:31 <LetoThe2nd> well it depends on the usecase, obviously.
Dec 10 11:26:17 <luneff> interesting: https://git.congatec.com/yocto/meta-openembedded/blob/a4657e4395e0714198c34f02c54043edb8baeafb/meta-oe/classes/breakpad.bbclass
Dec 10 11:37:23 <Ad0> hm putting DROPBEAR_EXTRA_ARGS in my distro.conf seems to do nothing
Dec 10 11:37:44 <Ad0> I guess it's not even a variable
Dec 10 11:40:37 <qschulz> Ad0: of course, because it's not in a file that is parsed by Yocto
Dec 10 11:40:51 <qschulz> it's in a file that is added to the sources via SRC_URI
Dec 10 11:40:54 <qschulz> so just override it
Dec 10 11:40:54 <Ad0> yeah I did a grep and had a quick glance , mistook it for an actual variable
Dec 10 11:41:16 <Ad0> lol I am actually gonna make it into a variable
Dec 10 11:41:21 <qschulz> Ad0: if it's only for your distro, you can have your new file in a subdir named after the distro
Dec 10 11:41:58 <Ad0> I thought that was only for machines
Dec 10 11:43:28 <qschulz> Ad0: no, distros too, but be aware that distro has precedence over machines
Dec 10 11:43:33 <qschulz> so you won't be able to mix it that well
Dec 10 11:43:40 <Ad0> right
Dec 10 11:43:48 <qschulz> but if it's really not specific to a machine but to a distro, it's fine
Dec 10 11:44:01 <Ad0> right here, I only care about distros. I have 2 machines and both can run 2 distros, prod and dev edition of the distro
Dec 10 11:44:25 <Ad0> so typically dev has remote ssh access 0.0.0.0 and prod has 127.0.0.1
Dec 10 11:45:09 <Ad0> I can have logic for it in the bbappend or you say it can be a certain dir structure
Dec 10 11:45:38 <Ad0> I have no idea how to form a search query for that structure though
Dec 10 11:47:57 <Ad0> how is the distro specific directory structure in a recipe dir?
Dec 10 11:48:22 <Ad0> the less script trickery the better! :)
Dec 10 11:58:15 <LetoThe2nd> Ad0: dirty trick: add a nonexisting filename to SRC_URI and build the recipe. the resulting error message shows all searched directories, in order.
Dec 10 11:58:44 <Ad0> I should override the dropbear recipe right?
Dec 10 11:59:10 <Ad0> sometimes I see files written in own recipies that strictly belongs to another recipe
Dec 10 12:00:55 <Ad0> there is poky/meta/recipes-core/dropbear/dropbear/dropbear.default already so
Dec 10 12:01:05 <qschulz> Ad0: have your own bbappend
Dec 10 12:01:25 <qschulz> provided you have meta-mylayer/recipes-core/dropbear/dropbear_%.bbappend
Dec 10 12:01:36 <qschulz> then you put your file in:
Dec 10 12:01:50 <qschulz> meta-mylayer/recipes-core/dropbear/dropbear/my-distro/dropbear.default
Dec 10 12:01:58 <Ad0> ah ok
Dec 10 12:02:11 <Ad0> thanks. LetoThe2nd also thanks for the trick
Dec 10 12:02:22 <qschulz> and you add FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
Dec 10 12:02:26 <qschulz> to your bbappend
Dec 10 12:02:36 <Ad0> yes I have also seen variations of that
Dec 10 12:02:42 <qschulz> no need to add it again to SRC_URI since it's probably added in the original recipe
Dec 10 12:03:00 <Ad0> like "${THISDIR}/files:"
Dec 10 12:03:18 <LetoThe2nd> i just had a weird idea. would it make sense to have a warning if a variable is set but never read, and vice versa?
Dec 10 12:03:37 <Ad0> meta-mender does that to their own variables
Dec 10 12:03:46 <Ad0> LetoThe2nd, it makes a lot of sense, at least with some kind of switch / argument
Dec 10 12:03:58 <Ad0> I have been thinking some variables like the one I set was actually used
Dec 10 12:04:00 <LetoThe2nd> that could help to quickly spot types, basically.
Dec 10 12:04:15 <Ad0> but it wasn't and it would have been picked up by that
Dec 10 12:04:19 <LetoThe2nd> like bitbake -Werror-all
Dec 10 12:04:26 <Ad0> yeah
Dec 10 12:05:53 <loblik> if I go with multiconfig to build system controller firmware. can I somehow disable building all the other packages except the recipe which builds firmware?
Dec 10 12:06:54 <qschulz> loblik: there was a talk about building a free-rtos app with yocto the ELCE of last year
Dec 10 12:06:59 <loblik> I don't want to endup with two images for distinct targets. I just need one package for different platform and include that firmware to main target image.
Dec 10 12:07:18 <rburton> loblik: meta-arm literally does that
Dec 10 12:07:25 <qschulz> loblik: you can do dependencies across multiconfigs
Dec 10 12:07:33 <qschulz> on packages specifically
Dec 10 12:07:35 <qschulz> IIRC
Dec 10 12:07:41 <qschulz> but rburton will know much more than I do :)
Dec 10 12:07:56 <rburton> meta-arm has recipes for scp-firmware, trusted-firmware-a, trusted-firmware-m and op-tee.
Dec 10 12:09:44 <rburton> if you go multiconfig then you just bitbake the firmware
Dec 10 12:10:01 <rburton> meta-arm currently doesn't do multiconfig for the firmware but its on our todo list
Dec 10 12:10:21 <Ad0> I think I will actually just use the the install_append and echo the variable defined in my distro file
Dec 10 12:10:32 <Ad0> then I can append from the one in the base config and stuff
Dec 10 12:10:57 <qschulz> Ad0: up to you, I generally don't like mixing mechanisms
Dec 10 12:11:23 <Ad0> right
Dec 10 12:18:46 <Ad0> qschulz, seems like I shouldn't have the same distro name as machine, ever
Dec 10 12:18:58 <Ad0> I don't of course but I see the paths being searched
Dec 10 12:19:33 <Ad0> distro is on the same directory level as machine so they can't be mixed. it's either or
Dec 10 12:24:43 <mmurto> Hi all! I'm trying to determine which recipes created which packages in a manifest file of an image with oe-pkgdata-util lookup-recipe <recipe-name>. It seems to work pretty well, but it doesn't find recipes for some specific packages, the ones alike kernel-5.4.61-yocto-standard. Does anyone know why is that so?
Dec 10 12:29:27 <Ad0> installing my own systemd services. should that be done in my own recipe or should I override some systemd recipe? I do it in my own main layer recipe that does "everything"
Dec 10 12:30:47 <erbo> Ad0: ship the systemd services in the recipe of the service, there's systemd.bbclass that provides most of the functionality
Dec 10 12:30:57 <LetoThe2nd> ++
Dec 10 12:31:21 <Ad0> thanks I do that now
Dec 10 12:52:47 <spiro> <body>
Dec 10 14:23:24 <gdk-pixbuf48> hello. anyone here?
Dec 10 14:25:51 <gdk-pixbuf48> I wrote my question on #poky but the channel seems to be dead
Dec 10 14:25:54 <gdk-pixbuf48>  I try to build poky and I encounter some weird issue, I searched through web and there is literally no answer to that mystery.
Dec 10 14:26:04 <gdk-pixbuf48> I run MACHINE=qemux86 bitbake core-image-minimal, just vanilla poky clone, yocto-3.2
Dec 10 14:26:12 <gdk-pixbuf48> every time I get "gdk-pixbuf-query-loaders No such file or directory" during core-image-minimal-1.0-r0 do_rootfs
Dec 10 14:26:33 <LetoThe2nd> soudns strange.
Dec 10 14:27:07 <LetoThe2nd> i can give it a try but will take some time.
Dec 10 14:28:22 <gdk-pixbuf48> it works for other people, just not for me and I have no idea how to attack this issue. I mean it's just basic poky build. I am sure it works for 100s of people in CIs around the world
Dec 10 14:28:44 <erbo> gdk-pixbuf48: what build host are you using?
Dec 10 14:29:35 <LetoThe2nd> erbo: very good point.
Dec 10 14:29:53 <gdk-pixbuf48> ubuntu 18.04.2 amd64
Dec 10 14:30:51 <erbo> that sounds supported enough :)
Dec 10 14:33:16 <erbo> gdk-pixbuf48: could you post the local.conf to some pastebin?
Dec 10 14:34:39 <erbo> gdk-pixbuf48: and do you have all of the packages listed on https://docs.yoctoproject.org/3.2/brief-yoctoprojectqs/brief-yoctoprojectqs.html installed?
Dec 10 14:34:53 <erbo> There's a nice apt-get line there, make sure all are installed
Dec 10 14:35:45 <gdk-pixbuf48> pastebin.com/a68aB3Ut
Dec 10 14:35:50 <gdk-pixbuf48> ok, let me check
Dec 10 14:37:44 <gdk-pixbuf48> something is installing, so maybe some package was missing. I will check and get back to you later if it still doesn't work
Dec 10 14:38:01 <gdk-pixbuf48> thanks a lot
Dec 10 14:38:47 <gdk-pixbuf48> nope still doesn't work
Dec 10 14:38:56 <gdk-pixbuf48> what a bummer
Dec 10 14:39:42 <erbo> I kicked off a build here, but I guess odds are it will just work.
Dec 10 14:45:45 <gdk-pixbuf48> thanks. I will get back to you later, maybe I will be able to provide some more detailed failure log but I can't paste the whole file
Dec 10 15:12:18 <RP> ndec, kanavin_home: https://reproducible-builds.org/reports/2020-11/ :)
Dec 10 15:24:43 <JPEW> kanavin_home: Good job on that!
Dec 10 15:25:02 <Sibert> Hi everyone. I'm struggeling with adding pulseaudio/bluetooth to my image. Can anyone point me to the right documentation because I can't find it
Dec 10 15:26:27 <RobertBerger> @RP I did some md5sum over a kernel and device tree a customer and me built and it was identical ;) so something happens with reproduce able stuff
Dec 10 15:29:21 <RP> RobertBerger: you used an insecure algorithm and have been hacked? :)
Dec 10 15:29:42 <RP> seriously, the reproducible stuff is starting to come together nicely :)
Dec 10 15:29:50 <RP> its nice it worked like that out the box
Dec 10 15:48:38 <wyre> why if I've set `DISTRO = "myown"` I see `DISTRO = "poky"` in the build configuration when I run bitbake?
Dec 10 15:54:17 <qschulz> wyre: where did you set iot?
Dec 10 15:58:45 <Ad0> hm should I pre-generate a host key for all devices for SSH server or should I map the host key to a writable place ?
Dec 10 15:59:22 <wyre> qschulz, sorry, it was my fault, now apparently is working as I expected
Dec 10 15:59:24 <wyre> iot?
Dec 10 16:08:26 <qschulz> it
Dec 10 16:09:42 <qschulz> Ad0: IIRC, keys are auto-generated on first boot
Dec 10 16:09:58 <Ad0> yeah but on a read only system they are generated on every boot
Dec 10 16:10:19 <qschulz> Ad0: then generate them during the image creation
Dec 10 16:10:20 <Ad0> so I a) have to direct the path to writable part or supply my own key
Dec 10 16:10:39 <JPEW> Ad0: You can redirect them to a r/w location; that's what we do
Dec 10 16:10:42 <Ad0> then it will be the same for all devices , which I guess is not a big problem?
Dec 10 16:10:51 <qschulz> Ad0: addendum to my own suggestion: unless you want to upgrade the system in which case meh
Dec 10 16:10:57 <Ad0> should it truly be unique for each device?
Dec 10 16:11:30 <Ad0> if the device is upgrade but it's on the shared data partition, then it's persisted
Dec 10 16:14:30 <Ad0> rootfs-postcommands.bbclass will actually force a config variable if I don't put an rsa key file there
Dec 10 16:15:07 <Ad0> https://github.com/openembedded/openembedded-core/blob/master/meta/classes/rootfs-postcommands.bbclass#L120
Dec 10 16:16:26 <Ad0> so should I a) put a real file there with content "dummy" or empty, and add in default config to point to another file, or b) use systemd to remap /var/lib/dropbear to /data/dropbear
Dec 10 16:17:55 <Ad0> I would need to put /etc/dropbear/dropbear_rsa_host_key there to trick that script lol
Dec 10 16:18:29 <Ad0> OR mount /var/lib/dropbear to /data/dropbear with systemd
Dec 10 16:18:41 <Ad0> I feel I should do the latter
Dec 10 16:19:19 <Ad0> but either way I need to actually know the inner workings of a bbclass to figure this out hehe
Dec 10 16:20:46 <qschulz> Ad0: what did you need to know about the "inner workings of a bbclass"?
Dec 10 16:23:26 <Ad0> if I had added DROPBEAR_RSAKEY_DIR to the /etc/default/dropbear without reading, it would have overwritten that variable
Dec 10 16:23:51 <Ad0> because it didn't detect that /etc/dropbear/dropbear_rsa_host_key
Dec 10 16:24:07 <Ad0> that's how I interpret it
Dec 10 16:25:43 <Ad0> more more correctly, I would have gotten 2 of them. where the last one is written by rootfs-postcommands.bbclass. since these are env vars it would simply overwrite mine in practice
Dec 10 16:41:14 <rpcme> Hello all - wondering if there's been any prior work on this - I have a need to use Apache Maven but I have a couple challenges with that - 1/ (building app) how maven is dealing with project dependencies and 2/ (building maven itself) you need maven to build maven, so now I have a bit of conundrum on the builder front.  any ideas?
Dec 10 16:41:53 <rpcme> I think /2/ is really the biggest problem at this point
Dec 10 16:52:35 <paulbarker> rpcme: It's always worth searching the layer index for a recipe: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=maven
Dec 10 16:53:05 <paulbarker> I've no idea on the status of that but it may be a place to start
Dec 10 16:56:35 <gdk-pixbuf48> hello again. Earlier I described my problem with building vanilla poky. I found post on SO with the very similar symptoms to mine: https://stackoverflow.com/questions/56181757/an-issue-with-postinst-intercept-scripts
Dec 10 16:57:16 <gdk-pixbuf48> Unlike OP, I use bitbake and it doesn't work for me even using standard set of tools
Dec 10 17:03:08 <RobertBerger> @RP - I just tried for fun and was very surprised ;) Another piece of Magic! I wish I could understand better how some of those magic things work.
Dec 10 17:16:43 <v0n> if my board is a commercial board but with a custom in-house designed daughter board on it, is it best if I define my own machine?
Dec 10 17:17:01 <fray> Maybe
Dec 10 17:17:08 <v0n> an Rpi with a custom daughter board for example
Dec 10 17:17:28 <fray> in my experience, if you need to adjust settings that are typically setup with the MACHINE configuration, serial ports, capabilities, like ethernet, kernel configurations, etc.. then it's a new MACHINE
Dec 10 17:17:44 <fray> but if you use the existing machine without modification, and it's just a different board -- then that isn't needed..
Dec 10 17:18:00 <erbo> gdk-pixbuf48: hmm, build succeded here
Dec 10 17:18:16 <v0n> fray: these are mostly connectivity for new devices such as usb and all, which requires a DTS though
Dec 10 17:19:01 <fray> under the current world, if you have a new Device Tree, then you likely want to specify a new machine.. but your new machine can inherit the general purpose one and save you work..
Dec 10 17:19:42 <fray> I'm currently working on something for the Xilinx FPGAs along that line.  There will be a general purpose machine (without a default DTB) specified, and then you can specify a machine and pass just the differences in yoru configuration, inheriting the generics..
Dec 10 17:19:53 <fray> not worked out all of the details yet, but that is the direction we're heading..
Dec 10 17:22:21 <v0n> fray: I see. So I can separate the recipes and stuffs specific to the company and its daughter board into a private layer and distribute only the generic layers to customers so that they can build they own recipes for the target, right?
Dec 10 17:23:40 <v0n> (if let's say most of the IP resides in the daughter board and what's connected to it)
Dec 10 17:23:45 <fray> yes..
Dec 10 17:24:56 <fray> so for the Xilinx stuff I was mentioning, I would expect that the end developer would do something like create their own layer, that would depend on meta-xilinx-bsp..  and then their custom software, drivers and configuration would be in their BSP layer,a nd all of the support software comes from meta-xilinx-bsp ... I would assume something like that can likely be done with the RPi as well.. you might hit a few snags, but ti shouldn't be too bad
Dec 10 17:26:43 <fray> also their machine.conf file would look something like:  include conf/machine/zynqmp-generic \n # local setting here....
Dec 10 17:30:11 <v0n> fray: got it. Maybe a new machine isn't required here. What I want is to deliver the hardware and "base" layers/recipes for them to integrate their own application, but without distributing some private parts of the hardware description (daughter board mainly) and some in-house apps and system conf.
Dec 10 17:31:17 <fray> put the private stuff in its own layer..  public stuff in it's layer and you should be good..
Dec 10 17:31:40 <fray> If you look at the Yocto Project Compliance (layers) stuff, there are recommendatiosn for distribution, BSP, and other layers that might be relevant
Dec 10 17:32:19 <v0n> exactly. And the private layer would contain stuffs like KERNEL_DEVICETREE_raspberrypi and other specifics
Dec 10 17:32:29 <fray> yes
Dec 10 17:32:42 <rpcme> paulbarker thank you - I would not have thought of putting it in this layer - I thought it would be been in meta-java
Dec 10 17:33:10 <v0n> so since they will have hands on the hardware, there's no reason to abstract a new "machine" here I think.
Dec 10 17:33:20 <fray> makes sense
Dec 10 17:35:28 <v0n> without the private layer they won't be able to build a complete system (let's say we have custom init and recovery routines, etc.) but we will be able to install their pre-built .ipk or squashfs application images
Dec 10 17:37:10 <fray> just remember to pay attaention to GPL compliance requirements... FSF interpretation is that the customary build system components need to be available.. (not everyone agrees what that means).. but the easiest wayt o fullfil that is just give the layers to rebuild them..
Dec 10 17:37:22 <v0n> (squashfs can be easily overlayed over the system to apply custom settings)
Dec 10 17:37:24 <fray> so if you are modifying any GPL (any version) stuff, consider that going in the public layer
Dec 10 17:38:43 <v0n> fray: does KERNEL_DEVICETREE_rpi += "private.dtb" apply here?
Dec 10 17:40:39 <fray> all depends on if the devicetree is being linked into GPL code (or needed to build it)
Dec 10 17:41:02 <fray> I know it's possible to embedded the DTB into u-boot, but I don't know if u-boot developers consider that to be linking or if that is a problem)
Dec 10 17:42:26 <kanavin_home> RP, JPEW: cheers :) I guess we can separately promote the holdouts, and invite people to work on them?
Dec 10 17:46:00 <kanavin_home> (once the actual world repro commits merge of course)
Dec 10 17:46:08 <kanavin_home> I see they are still in -next
Dec 10 17:49:31 <RP> kanavin_home: I just didn't want to tempt fate with the M1 build!
Dec 10 17:49:45 <RP> kanavin_home: we do need to promote that!
Dec 10 17:54:39 <T_UNIX> hi
Dec 10 17:55:16 <T_UNIX> is anybody else suffering from a failed ncurses build due to a failure of pseudo (https://wiki.yoctoproject.org/wiki/Pseudo_Abort)?
Dec 10 17:55:55 <T_UNIX> a core-dump upon statements such as `cat << EOF` (of which there are a ton in ncurses)?
Dec 10 17:58:41 <RP> T_UNIX: which distro is that running on?
Dec 10 18:23:17 <T_UNIX> RP Fedora
Dec 10 18:23:58 <fray> selinux maybe?  anything in the log file?
Dec 10 18:27:04 <T_UNIX> likely :-/
Dec 10 18:30:02 <T_UNIX> solved
Dec 10 18:31:29 <T_UNIX> I'm building inside a container so I'm using volumes
Dec 10 18:32:07 <T_UNIX> I had to relabel all the build files so that it would not fail to copy some labeled file using another context.
Dec 10 18:32:59 <T_UNIX> btw. se linux context and copy/move instructions: https://bugs.python.org/issue38893#msg382794 is some good news
Dec 10 19:04:41 <jkprg> Hi experts! I'd like to put /usr/* into separate partition. I've found how to do it with wic. But is it possible to split rootfs this way for runqemu purpose to test mounting?
Dec 10 19:32:55 <kiwi_29> hello..which package provides modprobe inside yocto. I removed busybox on my sysvinit based system and all hell broke loose
Dec 10 19:33:12 <kiwi_29> Is there a package which I can install which provides all the applets provided by busybox?
Dec 10 19:40:01 <paulbarker> kiwi_29: I usually figure questions like that out by looking at what provides the utility on my host system
Dec 10 19:40:34 <kiwi_29> I agree .. with so much going on ..I almost forgot there is also https://layers.openembedded.org/layerindex/branch/master/recipes/?q=modprobe
Dec 10 19:44:44 <kiwi_29> Thanks paulbarker .. I did exactly that ... looked man page for modprobe and found it as part of kmod. ... therefore https://layers.openembedded.org/layerindex/branch/master/recipes/?q=kmod
Dec 10 21:25:28 <psiva87> Hi everyone, I have a yocto recipe which uses cmake to install some binaries in {bindir}, how can I add it to sysroot/rootfs?
Dec 10 21:51:51 <bluelightning> psiva87: for the rootfs (image), you just need to know what package that binary is going into, assuming it's not the main package for the recipe (same name as the recipe)
Dec 10 21:52:08 <bluelightning> psiva87:  for the sysroot (what other recipes with that recipe in DEPENDS see) we don't usually install target binaries, assuming this recipe is building for the target that is
Dec 10 22:05:48 <bobbyJ> Greetings!  I'm trying to install a recipe to build libevhtp into my rootfs and supply the rootfs with the dev packages (so the necessary headers).  My recipe, even though it builds the libevhtp correctly, and generates a *-dev package, those header are never installed into my rootfs.  I've included 'dev-pkgs' in my image install.
Dec 10 22:06:30 <bobbyJ> Secondary - is there already an existing libevhtp recipe somewhere?  I've not been able to locate one
Dec 10 22:09:16 <bobbyJ> I was under the impression that installing dev packages would be a somewhat automagic process - meaning I would not need to manually install the necessary files myself in my 'do_install_append ()' step
Dec 10 22:10:28 <jbdubois> I'm looking to install rsync on yocto running on an arm64, Anybody have any luck doing that?
Dec 10 22:10:34 <kergoth> bobbyJ: that depends on your recipe and what you're building.
Dec 10 22:10:50 <bobbyJ> I'm happy to share my recipe kergoth
Dec 10 22:12:04 <bobbyJ> LICENSE = "BSD"LIC_FILES_CHKSUM = "file://LICENSE;md5=68e2a80f5f9020a66f4512962817cd66"SRC_URI = "git://github.com/criticalstack/libevhtp/"SRC_URI[md5sum] = "ee1ae46269309acbda568c42a93d1a88"SRC_URI[sha256sum] = "316ede0d672be3ae6fe489d4ac1c8c53a1db7d4fe05edaff3c7c853933e02795"SRCREV = "e200bfa85bf253e9cfe1c1a9e705fccb176b9171"S =
Dec 10 22:12:05 <bobbyJ> "${WORKDIR}/git"DEPENDS_append = "libevent"
Dec 10 22:12:13 <bobbyJ> gross
Dec 10 22:12:32 <bobbyJ> Thats not ideal...
Dec 10 22:12:37 <bobbyJ> ```
Dec 10 22:13:01 <bobbyJ> ```LICENSE = "BSD"LIC_FILES_CHKSUM = "file://LICENSE;md5=68e2a80f5f9020a66f4512962817cd66"SRC_URI = "git://github.com/criticalstack/libevhtp/"SRC_URI[md5sum] = "ee1ae46269309acbda568c42a93d1a88"SRC_URI[sha256sum] = "316ede0d672be3ae6fe489d4ac1c8c53a1db7d4fe05edaff3c7c853933e02795"SRCREV = "e200bfa85bf253e9cfe1c1a9e705fccb176b9171"S =
Dec 10 22:13:01 <bobbyJ> "${WORKDIR}/git"DEPENDS_append = "libevent"
Dec 10 22:13:11 <bobbyJ> ```LICENSE = "BSD"LIC_FILES_CHKSUM = "file://LICENSE;md5=68e2a80f5f9020a66f4512962817cd66"SRC_URI = "git://github.com/criticalstack/libevhtp/"SRC_URI[md5sum] = "ee1ae46269309acbda568c42a93d1a88"SRC_URI[sha256sum] = "316ede0d672be3ae6fe489d4ac1c8c53a1db7d4fe05edaff3c7c853933e02795"SRCREV = "e200bfa85bf253e9cfe1c1a9e705fccb176b9171"S =
Dec 10 22:13:12 <bobbyJ> "${WORKDIR}/git"DEPENDS_append = "libevent"
Dec 10 22:13:35 <bobbyJ> That didn't work how I thought it would
Dec 10 22:13:38 <bobbyJ> sorry for the garbage
Dec 10 22:13:41 <neverpanic> bobbyJ: Use a pastebin service.
Dec 10 22:13:52 <bobbyJ> yea
Dec 10 22:15:07 <bobbyJ> https://pastebin.com/NhKnFTCD
Dec 10 22:17:09 <bobbyJ> I effectively added 'dev-pkgs' to the IMAGE_INSTALL_append to a 'core-image-base' recipe
Dec 10 22:20:14 <bobbyJ> during the install step for the `libevhtp` build process, I can see its installing dev packages, etc..., this just never makes it into the core-image-base generated rootfs
Dec 10 22:28:33 <bobbyJ> https://pastebin.com/NhKnFTCD. <--- Thats the recipe, sorry for not stating that earlier
Dec 10 22:44:21 <bobbyJ> https://pastebin.com/NhKnFTCD This is a recipe I'm trying to use to install libevhtp into a core-image-base recipe.  I'm trying to get the dev package installed (so the headers installed into `/usr/include` of the final rootfs.  However this does not work.  ANyone have any insight or suggestions?
Dec 10 22:49:57 <JPEW> bobbyJ: If you dig into the recipe's ${WORKDIR}, you should be able to see if the files are being packaged correctly
Dec 10 22:51:22 <JPEW> bobbyJ: Also, 'dev-pkgs' is an image feature: EXTRA_IMAGE_FEATURES += "dev-pkgs"
Dec 10 22:52:04 <bobbyJ> Correct, I misspoke regarding dev-pkgs
Dec 10 22:54:16 <bobbyJ> I have verified that the dev-packages are being installed in the {WORKDIR}
Dec 10 22:54:53 <bobbyJ> in the packages-split directory, there are `libevhtp  libevhtp-dbg  libevhtp-dev  libevhtp-doc  libevhtp-locale  libevhtp-src  libevhtp-staticdev` folders, all with contents like you'd expect
Dec 10 22:56:24 <kiwi_29_> Hello ... I removed busybox from my SYSVINIT based system with this code in my distro.conf
Dec 10 22:56:30 <kiwi_29_> # Replace busybox
Dec 10 22:56:30 <kiwi_29_> VIRTUAL-RUNTIME_login_manager = "shadow-base"
Dec 10 22:56:31 <kiwi_29_> PREFERRED_PROVIDER_virtual/base-utils = "coreutils"
Dec 10 22:56:33 <kiwi_29_> VIRTUAL-RUNTIME_base-utils = "coreutils"
Dec 10 22:56:35 <kiwi_29_> VIRTUAL-RUNTIME_base-utils-hwclock = "util-linux-hwclock"
Dec 10 22:56:37 <kiwi_29_> VIRTUAL-RUNTIME_base-utils-syslog = ""
Dec 10 22:56:38 <bobbyJ> as well as in the `package` directory, I find the tree of what I'd expect to be installed into my rootfs (eg there's an include, lib, and src direcotry)
Dec 10 22:56:42 <JPEW> bobbyJ: Maybe try explictly installing libevhtp-dev ?
Dec 10 22:56:51 <bobbyJ> @JPOE
Dec 10 22:56:59 <kiwi_29_> Now ...the hddimg and the iso of the image which is generated crashes when I select install at boot time
Dec 10 22:57:03 <bobbyJ> @JPEW - do you mean by adding libevhtp-dev into my image?
Dec 10 22:57:11 <bobbyJ> I tried that as well, and get an interesting error
Dec 10 22:57:11 <JPEW> bobbyJ: Ya
Dec 10 22:57:13 <kiwi_29_> the error is /sbin/init not found
Dec 10 22:57:41 <kiwi_29_> is there any dependency on busybox based stuff in hddimg or iso images?
Dec 10 22:59:29 <bobbyJ> @JPEW --> https://pastebin.com/RNd3npcU (this is the error I get when I add `libevhtp-dev` to my image_install_append
Dec 10 23:00:26 <bobbyJ> For completeness JPEW , here's my image-recipe https://pastebin.com/6sYmMLsP
Dec 10 23:00:43 <JPEW> bobbyJ: Hmm, maybe libevhtp is empty?
Dec 10 23:01:40 <bobbyJ> Not sure what you mean by 'empty' ?
Dec 10 23:02:01 <bobbyJ> it pulls down the code from git, builds it and installs it in its {WORKDIR}
Dec 10 23:02:16 <JPEW> Sorry, I have to go eat supper.... my guess is the package is empty and being removed (static library maybe?), in which case there is a variable to allow a package to exist even though it's empty
Dec 10 23:02:39 <JPEW> ALLOW_EMPTY_${PN} = "1" maybe?
Dec 10 23:02:56 <bobbyJ> Okay, I'll give that a try.  Thanks for support!
Dec 10 23:03:11 <rburton> bobbyJ: "oe-pkgdata-util list-pkg-files -p libevhtp" will show you what packages exist and what is in them
Dec 10 23:03:33 <bobbyJ> yup - let me show you that output, maybe I'm just being crosseyed
Dec 10 23:04:36 <bobbyJ> Here's the output https://pastebin.com/TLrw78dW
Dec 10 23:05:23 <kiwi_29_> The exact error while installing image using the hddimg on my hardware is :
Dec 10 23:05:30 <kiwi_29_> Run /init as init process
Dec 10 23:05:44 <kiwi_29_> Failed to execute /init (error -2)
Dec 10 23:06:06 <kiwi_29_> Kernel Panic - not syncing : No working init found. . Try passing init= option to kernel
Dec 10 23:09:32 <bobbyJ> Hmm JPEW, I think you were right although I don't fully understand what you mean by empty.
Dec 10 23:09:55 <bobbyJ> I added the ALLOW_EMPTY_${PN} = "1" and it appears now that the dev packages are installed correctly
Dec 10 23:10:35 <kiwi_29_> I see here -> https://www.yoctoproject.org/pipermail/yocto/2019-February/044324.html     which says hddimg requres initramfs which requires busybox ..
**** ENDING LOGGING AT Fri Dec 11 02:59:56 2020