**** BEGIN LOGGING AT Mon May 28 03:00:03 2018 May 28 08:25:08 New news from stackoverflow: yocto, how to build ffmpeg dev packages May 28 09:33:43 is it possible to just compile two different kernels on yocto 2.4? May 28 09:34:03 I get linux-blah was skipped: PREFERRED_PROVIDER_virtual/kernel set to linux-imx, not linux-blah May 28 09:48:09 Potentially dumb question: Is yocto the right choice if I want to build an image for an embedded system which uses an existing distro image as its base? For example, if I want to use Fedora 27 as my "base image" and then use yocto to install/configure packages/drivers/system config (in a reproducible way) on top? I don't want to have to build the Linux kernel myself, I'd be happy to just use the Fedora minimal ARM and then make my modif May 28 09:49:10 Having a hard time searching for info about this, I guess because I don't really know terms I should be searching for. :) May 28 09:50:25 I don't think any tool exists to do want you want May 28 09:52:23 sam125: someone tried combining Yocto + Debian https://youtu.be/AShznMqvBQo May 28 09:52:35 sam125: but I definitely wouldn't suggest it May 28 09:56:12 Right, so most embedded devices would run their own custom distro? Why is that better than using an existing distro? May 28 09:56:29 I mean, in my simplistic view it's nicer if I just Fedora as then if a new kernel ships I can just take the latest version of Fedora and not worry, rather than having my custom distro possibly break. May 28 09:56:31 sam125: because you are not at the mercy of the distro vendor, and can customize things completely May 28 09:57:11 sam125: but you can certainly run fedora on your device if that's what you prefer. it just might be very hard to make it do what you want :) May 28 09:58:14 ahh I see. sorry, I'm still fairly ignorant about all of this stuff. I suppose it would depend on how complex/resource constrained your target is as well May 28 10:01:04 sam125: also, you might spend a massive amount of time just getting fedora to boot on your hardware, depending on how the vendor supports it. typically they provide a nice off the shelf yocto BSP layer on the other hand :) May 28 10:01:45 sam125: you are probably aware that Red Hat's bread and butter is the data center, and Fedora is essentially a testing platform for RHEL May 28 10:03:13 sam125: Why would you not just extend your Fedora installation with a few added packages using the tooling provided by Fedora, then, though? May 28 10:03:24 What benefits do you expect Yocto to give you in such a setup? May 28 10:03:51 neverpanic: to make "fedora great again!" May 28 10:06:29 ah yes, that makes sense. i suppose i'm lucky in that my target can boot generic images so i thought "why not just use the distro that we'll run our dev laptops on?" May 28 10:06:34 neverpanic: i wanted something that, from a fedora image, could automate the installation of custom packages/drivers/configuration. i thought that was part of the point of yocto but i'm starting to see that maybe it's not :) May 28 10:07:57 sam125: not only mabye not, it absolutely is not. ;-) and one common reason for doing a special embedded distro is for example, that is rather hard to beat desktop/dev environments into read-only operation May 28 10:10:35 or working without systemd May 28 10:10:44 or a million other things May 28 10:11:01 so as usual, it depends(TM) May 28 10:13:23 sam125: I think you'd be better off looking for a solution that installs custom packages/drivers/config on Fedora. May 28 10:13:41 Something similar to Debian's debootstrap + chroot + package manager invocations, maybe? May 28 10:19:20 ahh that all makes sense. thanks everybody, very helpful! :) May 28 11:47:17 yeah, debootstrap/multistrap is probably the closest thing there... May 28 12:05:54 mckoan: I fixed isue with fstab May 28 12:07:54 open-nandra: hey May 28 12:08:34 open-nandra: did you customized the .wks? May 28 12:08:46 mckoan: nope May 28 12:08:54 mckoan: sec looking for change May 28 12:10:12 mckoan: added this to mahcine.conf: # Do not update fstab file when using wic images May 28 12:10:12 WIC_CREATE_EXTRA_ARGS ?= "--no-fstab-update" May 28 12:10:23 mckoan: https://patchwork.openembedded.org/patch/121413/ May 28 12:10:28 mckoan: and it works fine May 28 12:20:02 hey guys, I'm having issues with my little dev board and I'm wondering if anyone else has seen a similar issue May 28 12:20:28 I've got a USB wifi chip connected, and it won't start at boot. it takes two ifups to take it up for some odd reason, as the first one will fail May 28 12:21:13 I'm using busybox for a lot of the binaries, could this be an isse? that implementation is missing so many options it's making my head hurt a bit May 28 12:22:31 open-nandra: thx I'm going to test it May 28 12:25:16 mckoan: ok May 28 12:52:19 open-nandra: perfect! thx May 28 12:59:33 mckoan: np May 28 13:22:40 It seems to be rocko is lacking proper ${AUTOREV} support on hg repos. At least it seems it doesn't, since it crashes with "bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception AttributeError: 'FetchData' object has no attribute 'moddir'", while specifying SRCREV with a specific rev works fine. May 28 13:23:43 Now, this is hurting us hard right now, so which is less work: To implement our own pre-processing workaround, or to fix the hg implementation in fetch2? May 28 13:24:58 sveinse: a workaround i use is "rev=tip" in source uri May 28 13:33:14 varjag: Ah, yes. That made it continue, but it does not set ${SRCPV} accordingly. How do you deal with that? May 28 13:34:49 i don't use srcpv May 28 13:35:30 varjag: ok, so you don't label the built packages with the source revision? May 28 13:35:51 no May 28 13:36:01 i'm at the early stage of converting a legacy project May 28 13:36:05 varjag: ok, thanks May 28 13:36:06 to yocto May 28 13:36:12 np May 28 13:46:21 hi guys May 28 13:46:50 I'm trying to build an image but i'm getting the error: "error: unpacking of archive failed on file /usr/include/python2.7: cpio: mkdir failed - Inappropriate ioctl for device" on do_rootfs task May 28 13:48:04 someone have ever seen this error before? May 28 13:48:19 i'm using fedora 27 and branch sumo May 28 13:58:43 The ExpansionError exception above is masking another exception, AttributeError. Is there a way to configure bitbake to print the traceback for the masked exception? May 28 14:07:21 sveinse, you can edit bitbake's code and put prints where you want or debug the way you want May 28 14:47:26 I think I've found the error in bitbake/lib/bb/fetch2/hg.py May 28 15:26:34 New news from stackoverflow: test can yocto image May 28 15:28:11 Which just uncoveres another colorful bug. ${AUTOREV} picks the latest commit in the commit-log, but unlike git, this commit can belong to another branch, so it can and will pick the latest commit regardless of branch :( May 28 18:08:15 Hello ... anyone familiar with bitbake massage related to multilib support? May 28 18:53:23 am I the only one seeing an installed-vs-shipped issue on the lastest builds using master for glibc-locale? May 28 18:54:08 I would take a stab at fixing it but have a feeling this one is better left to the experts May 28 18:54:33 /usr/share/i18n/charmaps/EUC-TW.gz May 28 18:54:35 /usr/share/i18n/charmaps/IBM868.gz May 28 18:54:36 ... May 28 18:54:45 /usr/share/i18n/locales/de_IT May 28 18:54:47 /usr/share/i18n/locales/csb_PL May 28 18:54:48 /usr/share/i18n/locales/brx_IN May 28 18:54:50 /usr/share/i18n/locales/es_HN May 28 18:54:51 ... May 28 18:55:00 /usr/lib/gconv/ISO8859-5.so May 28 18:55:01 /usr/lib/gconv/GBBIG5.so May 28 18:55:03 /usr/lib/gconv/BIG5.so May 28 18:55:04 ... May 28 18:55:36 glibc-locale: 841 installed and not shipped files. [installed-vs-shipped] May 28 18:57:21 easy enough to work around with INSANE_SKIP_${PN} = "installed-vs-shipped" May 28 20:26:05 determined why I would be the only one seeing this, incorrectly appended to DISTRO_FEATURES caused the issue **** ENDING LOGGING AT Tue May 29 03:00:04 2018